UML Notes – Relationships in Class Diagrams

References –

http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/class.htm

http://www.agilemodeling.com/artifacts/classDiagram.htm

http://www.objectmentor.com/resources/articles/umlClassDiagrams.pdf

http://matdev.blogspot.com/2006/06/aggregation-vs-composition.html

http://www.dotnetcoders.com/web/learning/uml/diagrams/classdiagram.aspx

http://www.visual-paradigm.com/VPGallery/diagrams/Class.html

Association:

The association relationship is the most common relationship in a class diagram. The association shows the relationship between instances of classes. For example, the class Order is associated with the class Customer. The multiplicity of the association denotes the number of objects that can participate in then relationship.1 For example, an Order object can be associated to only one customer, but a customer can be associated to many orders.

Generalization ( Inheritance ) :

A generalization is used when two classes are similar, but have some differences. Look at the generalization below:

Composition :

Composition is where you have a number of objects that make up another object – you can’t have a dog’s legs and liver and tongue etc, without having the dog object. The objects are composed. And therefore, if we delete a dog object, we loose all the objects it is composed of – cascading delete. So we fill in the diamond to signify that those objects are contained within that mother dog object. Same is true for Car and Engine/Carburetor

Aggregation :

On the other hand, we can have a set of objects, trees, for example, that when aggregated together can form a forest. We can still have a forest with no trees, and we can have a single tree. Trees can belong to other forests too. Same is true in the case of Ducks and Pond
So we DON’T fill in the diamond with aggregation.
The Diamond always goes on the side of the ‘group’ object.

Dependency :

Sometimes the relationship between a two classes is very weak. They are not implemented with
member variables at all. Rather they might be implemented as member function arguments. Consider,
for example, the Draw function of the Shape class. Suppose that this function takes an
argument of type DrawingContext.

Figure shows a dashed arrow between the Shape class and the DrawingContext class. This is the dependency relationship. In Booch94 this was called a ‘using’ relationship. This relationship simply means that Shape somehow depends upon DrawingContext. In C++ this almost
always results in a #include.

Advertisements

Leave a comment

Filed under OOAD

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s