UML relationships - dashed line vs solid line

What is the difference between these 2 relationships?

Edit: Also if you could provide a simple code example illustrating the difference, that would be really helpful!

I'm trying to give simple examples of the two types of lines.

In the first diagram, the solid line shows an association:

If the classes were declared in Java, this would be like ClassA storing a reference to ClassB as an attribute (it could be passed in to the constructor, created, etc.). So, you might see something like:

public class ClassA {
    ClassB theClassB = ...
    ...
}

In the second diagram, it shows a dependency:

A dependency is much weaker than an association. To quote from UML Distilled:

>With classes, dependencies exist for various reasons: One class sends a message to another; one class has another as part of its data; one class mentions another as a parameter to an operation. [...] You use dependencies whenever you want to show how changes in one element might alter other elements.

Again, using Java, a couple of examples exist: an argument of type ClassB is passed to a method, or a method declares a local variable of type ClassB:

public class ClassA {
    ...
    public void someMethod(ClassB arg1) {...}
    ...
    public void someOtherMethod() {
        ClassB localReferenceToClassB = ...
    }
    ...
}

Other ways ClassA could depend on ClassB without having an association (not an exhaustive list):

• ClassB has a static method that ClassA calls
• ClassA catches exceptions of type ClassB
• Whenever ClassB is modified, ClassA must also be modified (e.g., some logic is shared)

This webpage says enough I think The following text comes from it, but should be enough to understand the difference.

So basically the solid line is an association and the dashed/dotted line is a dependency.

> Associations can also be unidirectional, where one class knows about > the other class and the relationship but the other class does not. > Such associations require an open arrowhead to point to the class that > is known and only the known class can have a role name and > multiplicity. In the example, the Customer class knows about any > number of products purchased but the Product class knows nothing about > any customer. The multiplicity "0..*" means zero or more. > > A dependency is a weak relationship between two classes and is > represented by a dotted line. In the example, there is a dependency > between Point and LineSegment, because LineSegment's draw() operation > uses the Point class. It indicates that LineSegment has to know about > Point, even if it has no attributes of that type. This example also > illustrates how class diagrams are used to focus in on what is > important in the context, as you wouldn't normally want to show such > detailed dependencies for all your class operations.

Since my reputation is only 8 I can't place the images itself, but they can still be found on the webpage I mentioned at the start.

[EDIT]

I don't have code examples right here, but how I personally would explain it is as simple as a car and a door.

When a car has a door (or more) it's just a car

Car --- has a --> Door

But when you have a door which can be opened the door class will have a function like

public void openDoor(){
this.open();
}

To use the function above the car will have to create an instance of the door

Class Car(){
Door door1 = new Door();

door1.open();
}

In this way you have created a dependency.

So the solid line is just pointing an object(1) to another object(2), but when you start using the object(1) it becomes a dependency.

Your question gave me a good chance to learn myself, here is what I found -

Association: Ownership of another type (e.g. 'A' owns a 'B')

//@assoc  The Player(A) has some Dice(B)
class Player {
	Dice myDice;
}

Dependency: Use of another type (e.g. 'C' uses a 'D')

//@dep    The Player(C) uses some Dice(D) when playing a game
class Player {
	rollYahtzee(Dice someDice);
}

Here's a crisp ref I found - Association vs. Dependency

Okay, since you didn't accept the first answer; let me try.

Arrow 1: A normal association

UML has different types of lines and arrows. Above is the simple association arrow, that means that one class can have a link to the other class. Below I will explain each type WITH code examples.

• In the first example, you can see that there isn't really specified who knows who (who is the owner of the relationship). An animal can know the human and the human can know the animal. It's not specified and thus not really helpful for the programmer.
• In the second example, the artist can have a guitar. Because there is an arrow and there isn't one on the other side, we know that the guitar doesn't know the artist. A guitar is an object that can totally exist on its own and doesn't need anybody.
• In the third example, you see a marriage. Really simple; the husband knows the wife and the wife knows her husband. In our situation, the husband has only one wife and vice versa.

How do we accomplish this usually in code?

class Husband{
	Wife bestWomanInTheWorld;
	
	public Husband(Wife theWife){
		this.bestWomanInTheWorld = theWife;
	}
}

Because the husband always needs a wife, we put the required relationship in the constructor. Because an artist can have a guitar, we would leave the constructor empty like this:

class Artist{
	List<Guitar> guitars;
	
	public Artist(){
	}
	
	public AddGuitarToCollection(Guitar newGuitar){
		Guitars.Add(newGuitar);
	}
}

So, that's how we accomplish this in code (most of the time!). You won't usually need different types of lines and arrows if you are new to programming. Keep it simple.

Arrow 2: Dependency

Okay, so we know about normal associations which we will use most of the time. But when will we use the 'dependency' arrow? Well, lets define a dependency (wikipedia):

Dependency is a weaker form of bond which indicates that one class depends on 
another because it uses it at some point in time. One class depends on 
another if the independent class is a parameter variable or local variable of 
a method of the dependent class. This is different from an association, where 
an attribute of the dependent class is an instance of the independent class. 
Sometimes the relationship between two classes is very weak. They are not 
implemented with member variables at all. Rather they might be implemented as 
member function arguments.

If there is a connection, relation, association etc. that requires to be present, to the classA to work; it's a dependency. Example: Husband needs the Wife to exist. A car needs a wheel to be a car (and drive). A car factory needs a car class to make an object from it. Your RSSNewsItem class needs an XMLReader class to do anything.

When to use which?

Well, this is the only valid question in my eyes; since google shows alot of valid answers to your question. Try to never use a dependency in a class diagram because it usually means that you aren't specific enough. Always aim for associations, realisations etc. Only use realisations (in my opinion) if there is a required need to use an other class without maintaining a relationship. Example; Utility classes (like the XMLReader).

If you have any questions after reading this full explanation, feel free to ask. :-)

Dotted line indicates dependency to (in the direction of the arrow). Assuming you have assembled your source code neatly into separate files and headers for each class

• the give away is simply that the code includes the line #include ClassB.h.

HOWEVER The fact of the matter is that all class relationships (generalisation, realisation, composition, aggregation, association etc) all inherit the dependency relationship. For this reason I never use dotted arrows when documenting code. Where possible I would aim to document the relationship in more specific terms eg. diamonds, triangles etc. If I don't know the exact relationship my starting point is a solid line with arrows (an association, with (implicit) dependence).

Notwithstanding this the dotted arrow notation can be useful in other aspects of UML modelling eg. showing dependencies to requirements in Use Case analysis for example. NOTE The Thought Police would have us reduce coupling & dependencies between classes by using interfaces (pure virtual classes) as far as practical.

Whilst pure virtual classes offer the prospect of multiple inheritance and tightest coupling of all between classes as is possible. Interface classes have the advantage that they are made entirely out of dark matter and so totally invisible to the police. With this in mind it is possible to write c++ code with apparently zero coupling between classes -which they love because they never really did understand all those funny looking symbols anyway.

dotted mean implements (an interface) solid means extends (a base class)