View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

How to create good UML designs - Lander L. Basterra


Classes are depicted as boxes with three sections, the top one indicates the name of the class, the middle one lists the attributes of the class, and the third one lists the methods.The class diagram is used to define a detailed design of the system that would help the programmer to implement. The class diagram consists of interrelated classes. The relationship or association between the classes can be either an "is-a" or "has-a" relationship. Each class in the class diagram may be capable of providing certain functionalities. These functionalities provided by the class are termed "methods" of the class. Apart from this, each class may have certain "attributes" that uniquely identify the class.


An object is usually a noun in the description of a design. Objects both know things (they have attributes) and they do things (they have methods). A class is a representation of an object. Classes form the main building blocks of an object-oriented application. Although thousands of students attend the university, you would only model one class, called Student, which would represent the entire collection of students.


Classes are typically modeled as rectangles with three sections: the top section for the name of the class, the middle section for the attributes of the class, and the bottom section for the methods of the class. The initial classes of your model can be identified in the same manner as they are when you created your CRC cards, as will the initial responsibilities (its attributes and methods). Attributes are the information stored about an object, while methods are the things an object or class do. For example, students have student numbers, names, addresses, and phone numbers. Those are all examples of the attributes of a student. Students also enroll in courses, drop courses, and request transcripts. Those are all examples of the things a student does, which get implemented (coded) as methods.

An important consideration the appropriate level of detail. Consider a Student class which has an attribute called Address. But, addresses are complicated things. They have complex data, containing street and city information for example, and they have behavior. So, by introducing an Address class, the Student class has become more cohesive. It no longer contains logic (such as validation of the address) that is pertinent to addresses. The Address class could now be reused in other places, such as the Professor class, reducing your overall development costs. Furthermore, if the need arises to support students with several addresses, a student may live in a different location than his permanent mailing address, such as a dorm; having a separate class to implement addresses should make the addition of this behavior easier to implement.


Objects are often associated with, or related to, other objects. So in your UML design the relationship among classes represent their associations. For example, the Student class is associated to the
Address class since there exists a relation between these two classes (a student lives at certain address).

When you model associations in UML class diagrams, you show them line connecting two classes. The label, which is optional, although highly recommended, is typically one or two words describing the association. For example, in the previous example we could label the relationship between Student and Address as (lives on).

It is not enough simply to know students live at some address. How many addresses do student have? None, one, or several? Furthermore, associations are often two-way streets: not only do students live at some address but certain address is populated by one or several students. This leads to questions like: how many address does the student have? The implication is you also need to identify the multiplicity of an association. The multiplicity of the association is labeled on either end of the line, one multiplicity indicator for each direction. For example,

0..1 means Zero or one

1 means One only

0..means Zero or more

1.. means One or more

n means Only n (where n > 1)

0..n means Zero to n (where n > 1)

1..n means One to n (where n > 1)

Another option for associations is to indicate the direction in which the label should be read. This is depicted using a filled triangle, called a direction indicator. For instance, in our example we labeled the relation between the Student class and the Address class as lives on , so using what we already said, we could label this relation also with a small black triangle on top of the label pointing to the Student class since a student lives on certain address. Direction indicators should be used whenever it isn’t clear which way a label should be read. My advice, however, is to use them all the time.

The associations among classes have also arrowheads. The arrowheads on the end of the line indicate the directionality of the association. A line with one arrowhead is uni-directional whereas a line with either zero or two arrowheads is bidirectional. Officially you should include both arrowheads for bi-directional assocations, however, you could just drop them is the relation is bidirectional.


Similarities often exist between different classes. Very often two or more classes will share the same attributes and/or the same methods. Because you don’t want to have to write the same code repeatedly, you want a mechanism that takes advantage of these similarities. Inheritance is that mechanism. Inheritance models “is a” and “is like” relationships, enabling you to reuse existing data and code easily. When A inherits from B, we say A is the subclass of B and B is the superclass of A. So if B is a subclass of A, B inherits all the methods A has. The UML modeling notation for inheritance is a line with a closed arrowhead pointing from the subclass to the superclass.

Many similarities occur between the for example the Student and Professor classes among their attributes and methods, for example name, and method getAdress(). To take advantage of these similarities, we can created a new class called Person and have both Student and Professor inherit from it. This structure would be called the Person inheritance hierarchy because Person is the root class. The Person class is abstract: objects are not created directly from it, and it captures the similarities between the students and professors. Abstract classes are modeled with their names in italics, as opposed to concrete classes, classes from which objects are instantiated, whose names are in normal text. So we could move the attribute name and method getAdress() to the Person class.


Sometimes an object is made up of other objects. For example, a plane is made up of wings, engines, landing gear, flaps, and so on. So we depict a composition association if one class is part of another. For instance in our example, there would be a composition association between the Wing class and the Plane class. We represent this in the UML diagram by instead of putting the arrowhead at the end of the line that marks the relation between Plane and Wheel with a filled rhombus. This rhombus must touch the class that contains the part. The other end doesn't have anything.


In your design, it might be the case that you have self dependent classes. For example, the class Manager clearly manages him/herself. Therefore we can represent this in the UML diagram by having an association line that points to the same class, so in our example, we could represent the previous situation by a line that leaves the Manager class and points to itself.


Like when you code it is always a good idea to have comments, it s also a good idea to have some comments in your class diagram. Comments are created using a rectangle and draw the upper left corner as if you had fold the corner to the inside of the rectangle. Then write whatever your comment is and use a dotted line to make the association between your comment and whatever your comment is about; it can be a class, an association, a method. You can also have comments that don't point to anything, for example the one that you would make to write down your name, the name of the project and the like.


The following represents a Class Diagram made by the Global Trail team for their final project which was designing Oregon Trail.
Note: The composition association between the Trip class and the classes Location and Environment should be backwards since Trip
is the class that contains these two classes.

ClassDiagram.jpg

Links to this Page