UML Guide v2.1
Author: Rajinder Yadav
Date: Oct 4, 2007
UML Class Element
A UML class is defined by a rectangle having 3 segments. The segments are define as:
- identity, class name
- state, class variables
- behaviour, class methods
| Student |
-name:string
-GPA:int
-Dept:string |
+AttendClass()
+DoHomework()
+TakeExam() |
Diagram 1 - Class Diagram
In diagrams that only need to display hierarchical or dependency relationships, a class can be shown without state and behaviour. The following diagram shows a "student/school" relationship.
Diagram 2 - Class Diagram
Switching the roles, we also have a "school/student" relationship where the school "teaches" student.
Accessibility
Each method and state variable has an access privileges which can be defined as: public, protected, and private.
| Access | Description |
| public | Denoted by a "+" sign.
Provides global access rights, all external class can access methods and variables declared as public. |
| protected | Denoted by a "#" sign.
Only derived class can access methods and variables declared as protected. |
| private | Denoted by a "-" sign.
Class methods and variables are only accessible from within the class. |
Table 1 - Access Privileges
Class Hierarchy (Generalization)
A class hierarchy shows a parent/child relationship, also known as a "is-a" relationship. The child class is always the descendant of the parent class. Said another way, a parent class is known as a base class, while the child class is considered the derived class. You will always hear the word sub-classing when a software developer is talking about deriving a class, as the two words can be used interchangeably.
To show the parent/child relationship, a connecting arrow will extend from the derived class to the base class showing the lineage. Note the arrow is different than other arrows used to display relationship. The line drawn is solid and the arrow head is hollow with a triangle shape. The diagram that follows shows class Person as the base class from which class Student and class Teacher are derived.
Diagram 3 - Class Hierarchy
Since a student and a teacher "is-a" person, it makes sense to place all shared attributes(state) and methods(behaviour) in the base class. If we were to create another class called "GradStudent" that derived from class Student, then class Student would be the base class for class GradStudent. Likewise, class Person would be the base class for both class Student and class GradStudent.
|
Note: Cyclical inheritance is forbidden. A class cannot inherit from itself, nor can any parent inherit from it's child. Some languages like C++ allow multiple inheritance, were the child class may inherit from one or more parent classes.
|
Base Class
A software designer will create a base class allowing common attributes and behaviour to be isolated from two or more related classes. A base class helps to reduce code duplication, moreover errors are reduced because there is only a single place to make code changes for shared functionality. The base class facilitates code reuse, if we ever need to create a new class called "Dean", then we would simply derived it from class Person. This way class Dean would inherits characteristics from class Person for free! It goes without saying, that any changes made to the base class will affect all derived classes, so care needs to be taken when such changes are performed.
Derived Class
A derived class will always have one or more base class. All derived classes inherit the state and behaviour from their base class with respect to the accessibility right of the base class as described in table 2.
| Base Accessibility | Inheritance |
| public | Public methods and attributes are inherited and remains publicly accessible. |
| protected | Protected methods and attributes are inherited and remains protected. |
| private | Private methods and attributes cannot be inherited.
They are present in the subclass, but access it off limits. |
Table 2 - Inheritance
Implementation Class
An implementation class is any class that provides supporting code for one or more inherited abstract members. An implementation class can be a base class or a derived class, and it can also be a abstract class.
Concrete Class
A concrete class is any class that is code complete and declares no abstract members. A concrete class can be a base class or a derived class.
Abstract Classes
An abstract class will always be a base class in a hierarchical relationship and require that other classes inherit from it. A pure abstract class is different from an general abstract class in that a pure abstract class has no implementation code. A pure abstract only defines the method signatures that derived classes are required to implement, also it may contain state variables. An abstract class may in turn subclass one or more abstract classes, but it is still consider a base class in the sense that it is lacking implementation code and needs to be subclassed further by an implementation class. An abstract class may have one or more implementation/concrete class, that specialize behaviour.
A UML abstract class will have it's name italicized, I find this was a poor choice for notation style because it's had to notice so I like to use a stereotype to make it more prominent. Abstract methods, lacking implementation code will also be italicized.
| <<Abstract>>Shapes |
| +Draw() |
Diagram 4 - Abstract Class Diagram
|
Note: unlike a "pure" abstract class, an abstract class can contain some implementation code. For a class to be considered abstract it needs to only have one method that is declared abstract (having no implementation code). It needs to also be mentioned that an abstract class cannot have instances of objects created from it. Objects may only be created from it's derived non-abstract classes. See Object Diagram for more information on the meaning of objects.
|
The software architecture will use an abstract class among related classes when a common interface needs to be declared for interaction, but the actually implementation of the common interfaces will differ. The power of abstract class shine when we consider polymorphic behaviour!
As you have already encountered, there is a specialization of the pure abstract class called the interface. The interface only declares method signatures. The UML interface notation is similar to the class notation and contains the stereotype "<<Interface>>".
Interface Realization
A class implements an interface by realizing it, it does not subclass by using the generialization process. When showing that a class supports an interfaces, a realization association must be created between the clase and interface. An dashed line arrow with an arrow-head shaped like a triangle is drawn from the class pointing to the interface as shown below.
Diagram 5 - Interface Realization
The above diagram shows there are at most 2 drivers in the car, one does the actual driving and the other does the navigation. In-order to control the car, an interface IRallyDriver to the "Driver" object must be acquired. Likewise to navigate, an interface INavigator must to the "Navigator" (Driver) object must be acquired. The Driver class realizes two separate interfaces. Also class Driver denotes there is an association between instance of class Drivers, their roles are labeled in bold as driver and navigator.
There is an important detail missing from the above diagram, since the Automobile class contains the Driver class, how exactly does the driver control the car? The simplest way to do this would be to draw a "uses" (dependancy) association from the Driver class to the Automobile class. If one wants to stick to using interfaces, a better design approch like the next one would suffice.
Diagram 6 - Interface Generalization
Things to note here are the following. First we have provided class Automobile with an interface. Next we've extracted driving control from interface IRallyDriver into a base interface IDrive. Both IRallyDriver and IAutomobile inherit from IDrive to provide their respective interactions, and each adds a new method signature. Finally a dependency association is made from class Driver to class Automobile to show that the driver uses the car to race.
Polymorphic Behaviour
Polymorphic behaviour is the ability of a single class to carry out different behaviour for the same message. Consider the following shape drawing classes, given a reference to anyone of these class, you would know what type of shape that would get drawn when one the Draw( ) method is called. This is because we have context information to reference when performing an operation, namely the class name. This is not polymorphic behaviour, but the example will give rise to it as we evolve the design.
Diagram 7 - Drawing Classes
Consider a CAD/CAM application that needs to be able to render various shapes at different coordinates. The problem we face will be how do we contain these different shapes. Lets assume we are storing them in an array, and we want to be able to loop through the array and draw each shape one at a time until everything has been rendered. The problem is that an array, like any other container can only store homogeneous objects, unfortunately we have 3 heterogeneous objects. We can re-factor the design and create a helper class with a "uses" relationship. Then we can use a "Shapes" container that stores instance of class Shape that draws either a circle, rectangle or a 3D box by delegating the behaviour to the appropriate drawing class.
Diagram 8 - Shape Classes
If we do this, we run into another problem of having to differentiate between the various drawing methods to call. It would be better if we could store each of the drawing objects in a single container and call a single Draw( ) method that would render the right shape for us. The final solution does this by turning the design upside-down on it's head!
Diagram 9 - Polymorphic Classes
We make class Shape an abstract (base) class that defines only a single method called Draw( ). All the implementation drawing code will remain with each of the drawing classes. Since each drawing class is derived from the same base class, the CAD/CAM application can now store a reference to the base class in some type of "Shape" container. All that needs to be done now is make a call to the Draw( ) method and the right shape will be drawn.
The Shapes container hold one type of object, and it sends the same message to each contained object, but it is the object that know what type of shape to draw! This is what polymorphic behaviour is, the ability to carry out a different behaviour based on the type of object referenced using the same method call. We can get away with using a single method vs 3 methods because we are subclassing rather than delegating the behaviour as the case was in diagram 8.
|
Note: with the delegation design we require two class instances, one for the drawing class (Circle, Rectangle, 3DBox) and another for the Shape class that gets stored in the container and references a drawing class. With sub-classing and using polymorphic behaviour, we get the same thing by having to create a single class instance for each drawing class and storing a reference to it's base class. We do this by taking an instance of the derived drawing class and type-casting it to the base class Shapes and then saving a reference to it.
|
Class Diagrams
Class are the building blocks of a software architecture. A class diagrams is used to show hierarchical relationships as we have seen. A class diagrams can also be used to show other relationships, like whole/part "has-a" relationships using aggregation and composite connectors, interaction "uses" relationships with dependency arrows, or associations with connecting lines. The following diagram show a hypothetical class interaction digram.
Diagram 10 - Class Interaction
Like in the real world, there can be many instances of a class that will have associations and interaction amongst themselves. For example, student in a class that are assigned to work in a team for a lab project. All student need to interact with their teacher, and students on the same team must be able to talk to each other. However student cannot interact with students on other teams. Finally there can only be 2 students on a team. Here is one possible way to diagram this using a class diagram.
Diagram 11 - Class Interaction
Items to note in this diagram are the student to student "team" association. Team constraint size. The associated lab report that is handed from the teacher to the student and return from the student to the teach upon completion. The lap report is the actual data passed between teach and student. In the "Object Diagram" section you will see how this can be represented using an object interaction diagram.
Copyright © 2007 Rajinder Yadav, All rights reserved
UML logo are trademarks or registered trademarks of the Object Management Group, Inc. in the United States and other countries
|
