Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

UML Guide v2

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 2

UML Guide v2.

1
Author: Rajinder Yadav Date: Oct 7, 2007
Dependency In UML modeling as in life, UML elements can be related in many ways. Relationships are represented by a connecting line between two UML elements. The relationship can be directed, stating the form of communication, control or awareness is one way. A directed relationship will be shown with one end having an arrow. Usually this type of relationship is a "uses"relationship and is called a dependency.

Diagram 1 - Dependency

Usually the "using" end in a relationship will be aware of the other end it's using, but it's not always the case the "used" end is aware who is using it. Think of an application that needs to log errors to a file, the logger will not know who is sending it data, all it is told is what data to write to the log file. Association For relationships that are bidirectional, the common way to draw the relationship is with a solid line connecting the two UML elements without arrows. This type of relationship is called an association. You can still choose to draw two directed lines denoting each type of relationship, but too many line can clutter up diagrams unnecessarily.

Diagram 2 - Association

The diagrams above show that both UML elements are aware of each other. The document is responsible for the creation of the view, but it is the view that "uses" the document to get data to be displayed. The document doesn't control the view, it is the view that pulls the data from the document. From time to time the document may send Refresh or Update notification to the view when data is changed. Essentially both diagrams show the same thing, just take care to note the placement of the labels on the associations. Aggregation There are times when you need to show a whole/part relationship, where one thing contains zero or more other things. Now you might be wondering how something can contain "zero" of something? This really should be understood to mean that the containing thing doesn't necessarily need the presence of the contained things in order to exist. The following diagram displays this clearly. The containing UML element will have a hollow shaped diamond on the connecting lines. A school holds both zero or more teachers and students, but the school, students and teacher can exist on their own as well. This is a weakly-coupled relationship and is called an aggregation.

Diagram 3 - Aggregation

Composition There is a special whole/part relationship where one thing contains one or more things. This is a more stronger relationship where one needs the other in order to exist. Here are two diagrams that display composite relationships. The following diagram displays this clearly. The containing UML element will have a solid shaped diamond on the connecting lines. In the first diagram, both the human and heart need each other in order to exist. In the second diagram, a car cannot exist without wheels, an engine and doors, yet the doors, engine and wheels that make up the car can exist by themselves.

Diagram 4 - Composition

Note: An aggregation and composition is also known as a, "has-a" relationship, such as a human "has-a" heart. Multiplicity In a whole/part diagram, there needs to be a way to convey a count of the contained things in a short-form. This is shown as labelling each end of the relationship with a number, or with an "*" asterisk for a value of "zero or more". In the composition diagram (Dia.4), a human has only one heart, read another way, a heart can only belong to one human. In the association diagram(Dia.3), we see that zero or more teachers belong to a school. Finally, we may also have many to many relationship, take for instance students and classes. A student can be enrolled in zero or more classes, while a class can teach zero or more students, this type or association would be labeled as, "*..*" along the connecting line. Mul Description 1 One and only one. 0..1 Zero or one. 0..* Zero or more. * Zero or more. 1..* 1 or more. I..J From I to J (integer values) *..* Many to many.

Table 1 - Association Multiplicity

Previous

Next

You might also like