UML Newbie Guide

IOPROG/Ingmar Olsson

UML Newbie Guide

UML is a modelling language to specify, visualize, construct and document software systems. UML contains a number of modeling graphical tools, among them: - Use case diagram for organizing and modeling behavior of the system - Interaction diagram for interaction, consisting of a set of objects and their relationships, including the messages that may be dispatched among them. Interaction diagrams address the dynamic view of a system - Statechart diagram for state machines, consisting of states, transitions, events and activities. Statechart diagrams address the dynamic view of a system. - Class diagram for classes and their relationships. These diagrams are the most common in modeling object-oriented systems. Class diagrams address the static process view of a system. This paper introduces UML and its notations used for static structure, class diagrams and their relationships. The bible for UML is The Unified Modeling Language User Guide written of the original inventors of UML, Grady Booch, James Rumbaugh and Ivar Jacobson, ISBN number 0-201-57168-4.

Class Diagrams in UML

Class diagrams describe classes and different kinds of static relationships: associations, aggregation, inheritance , interface.

The class diagram is represented as a rectangle with three compartments, showing the class name, attributes and functions respectively. Though, any information deemed irrelevant to the application at hand may be omitted from a UML diagram. A class may be represented by two compartments, if attributes ar not important, or even with onr compartment, if just the name of the class is useful. Not all features have to be shown, if some are omitted, an ellips () is used. Static declaration is underlined. The visibility indicators are + for public access, for private access and # for protected access.

UML Newbie Guide

IOPROG/Ingmar Olsson

Operations are represented using syntax different from C++/Java/C# and have the following syntax/form: <visibility> <name>(<parameters>): <return type> The corresponding notation in C++, Java and C# are representented by the following classdeclarations: C++:
class MyClass { public: void setPrivateVar(int PrivateV) {privateVar = privateV;} int getPrivateVar() {return PrivateVar;} private: int privateVar; static int staticVar; }

Java:
public class MyClass { public void setPrivateVar(int PrivateV) {privateVar = privateV;} public int getPrivateVar() {return PrivateVar;} private int privateVar; static int staticVar; }

C#:
public class MyClass { public void setPrivateVar(int PrivateV) {privateVar = privateV;} public int getPrivateVar() {return PrivateVar;} private int privateVar; static int staticVar; }

Relationships in UML
There are different kinds of static relationships in UML: Inheritance Specialization/Generalization Association Aggregation Dependency Interface/Realization - Inheritance is a specialization/generalization relationship between objects of the specialized elements (child) and objects of the generalized elements (parent). - Association is a structural relationship that describes links or connection between objects.

UML Newbie Guide

IOPROG/Ingmar Olsson

- Aggregation is a special kind of association. - Dependency is a weaker form of association and is a semantic relationship between objects in which a change in one object (independent) object may affect the semantics of the other (dependent) object. The independent class gain access to the dependent class through a parameter of one of its member functions. - Interface/Realization is a semantic relationship that is encountered between interfaces and the classes or components that realize them and between use cases and the collaboration that realize them.

Comments
Comments can be added to UML diagrams, using rectangles with their upper-right corner turned down. Each comment is attached by a dashed line to the appropriate element of the diagram.

Inheritance - Specialization/Generalization
UML uses an arrow with a hollow end to point from the derived class to the base class.

UML Newbie Guide

IOPROG/Ingmar Olsson

The SubClass is also called the child class of the BaseClass, and the BaseClass called parent class, or SuperClass for the SubClass. The relationship is called inheritance. This relation is often described with: SubClass is-a type of BaseClass. C++:
class BaseClass {}; class SubClass : public BaseClass {};

Java:
public BaseClass {}; public class SubClass extends BaseClass {};

C#:
public BaseClass {}; public SubClass : BaseClass {};

Association
Association between classes is supported in the code by fields/attributes/variables that holds a pointer or a reference to the other objects. An association describes a weaker coupling between the objects in a relationship than aggregation does. An object uses another object but has not the ownership and the lifetimes for the objects dont need to be the same.

An association is implemented in C++ using a pointer.

class Associator

UML Newbie Guide

{ private: Associatee* associatee; };

IOPROG/Ingmar Olsson

class MotorFordon { private: Person* owner; };

An association in Java and C# most often is represented by a variable/field that holds a reference to other objects.
public class Associator { private Associatee associate; }

public class MotorFordon { private Person owner; }

Multiplicity
Objects can hold arrays or vectors of other objects, or they can hold many of the same kind of objects in a separate variable. In UML this is shown by placing a mulitiplicity indicator on the far end of the association. The multiplicity indicators can be used in the following way: - A range of the form i .. j, where i < j and I and j are non-negative integers. To represent infinity, j is equal to *: 1 .. * represents at least one object - A single number i to represent i .. i - A * to represent 0 .. * - A discrete range, such as 1,3

UML Newbie Guide

IOPROG/Ingmar Olsson

Aggregation

This relation is often described as a has-a relation. An aggregation is a whole or part-of relationship. In UML, aggregation is an association denoted by a hollow diamond at the end of the relationship that specifies the aggregator/whole part. The two ends of the relationship is also called roles. A relationship as well as its roles, can be labeled. When labels are missing, the roles are named after the target classes. There are two types of aggregations: standard aggregation and composition. C++: class Aggregator { private: Aggregatee aggregatee; }; Java/C#: Public class Aggregator { private Aggregatee aggregate; }

C++: #include Studentname.h class Student { private: StudentName ettName; }; Java/C#: public class Student { private StudentName ettName; };

UML Newbie Guide

IOPROG/Ingmar Olsson

C++: #include Motor.h class MotorFordon { private: Motor enMotor; }; Java/C#: public class MotorFordeon { private Motor enMotor; }; The aggregator class Student has a name aggregatee class StudentName. Based on the multiplicity indicators, each student has exactly one name, but the same name may be used to name many students. Or a vehicle MotorFordon has-a engine, Motor. Aggregation does not imply lifetime dependencies between the classes. For example, the students can change their names. If both ownership and lifetime dependencies are required, then they can be expressed using a specific kind of aggregation called composition (or composition aggregation). A composition implies that the part object may belong to only one whole object ant the composer and compose have identical lifetimes. In UML, a composition is denoted by a filled diamond at the end of the relationship that specifies the composer. Changing the aggregation to composition in the Student and MotorFordon examples would imply that the students name and the motor could not be changed. To clarify this concept, consider an example of a class Circle that uses the class Point to denote its origin. Not only is a point part of a circle, but also a point and a circle have the same lifetime: a point is deallocated together with its corresponding circle.

As with an aggregation, the code generated is exactly the same as for an association, see above. In C++ there is a lot of use of this relationship, but Java and C# does not have a lot of use of if. In Java and C# destruction happens behind the scene by the garbage collector. In C++ there is a need to manage the lifetime of an object.

UML Newbie Guide

IOPROG/Ingmar Olsson

Dependency
Dependency expresses the weakest coupling between two classes. The dependency is shown as a dashed arrow. With an association, a field/attribute/variable is used/created to support the relationship. A dependency does not use a field/attribute/variable. Therefore the relationship must be supported through another means. Possible ways are: - global supplier object and is therefore accessible to the client - supplier object is passed to the client as a parameter to an operation - supplier object is declared locally within an operation of the client

C++: class Instantiator { public: Instantiatee* createInstance(); { return new Instantiatee; } }; Java/C#: public class Instantiator { public Instantiatee createInstance() { return new Instantiatee; } }

Interface/Realization

UML Newbie Guide

IOPROG/Ingmar Olsson

C++:
class Interface1{}; class Class : public Interface1 {};

Java: interface Interface1 {} public class Class1 implements Interface1 {} C#: public interface Iinterface1 {} public class Class1 : Iinterface1 {}

Stereotypes
Stereotypes appear between guillement characters, usually above the name of the class or relationship. These help us figure out what types of classes or relationship we are dealing with in our model. Association stereotypes A create B
public class A { public B createB() { return new B; } }

A local B
public class A {

UML Newbie Guide

public void f() { B b = new B(); //Use b locally } }

IOPROG/Ingmar Olsson

A parameter B. The same as

public class A { public void f(B b) { //Use B as a parameter } }

A delegate B
public class A { private B b; public void f() { b.f(); } }

Class/Interface stereotype interface. Used for interface classes, se chapter Interface/Realization.

Example
The class Shape has two protected points (aggregation). Shape has a static private datamember n that counts the number of figures created Rectangle is a derived class by Shape, inheritance. A notation describes how the memberfunction area() calculate the area.

10

UML Newbie Guide

IOPROG/Ingmar Olsson

Reusability through Object Composition

To reuse functionality in object-oriented system there are two techniques: - class inheritance - object composition Object composition can be implemented with two techniques: - by value, using nested object - by reference, using references or pointers By value: Associator Associatee

11

UML Newbie Guide By reference:

IOPROG/Ingmar Olsson

Associator

Associatee

By value object composition implies a static structure. While access to objects is efficient (no need for indirect access through pointers or references), copying large object can be inefficient. By reference object composition is defined dynamically. The most important advantage of a by reference object compositon is that it can be used for polymorphic programming. A specific application of object composition is delegation, in which an object that is receiving messages, a delegator, delegates these requests to a delegate object. Often combined with inheritance delegation is commonly used in design patterns.

Reusability Inheritance versus Delegation

Inheritance is a technique to help support reuse of interface and implementation. This kind of reusabiblity is call white-box reusability because the internals of the parent classes are visible to the derived classes. However, inheritance is a compile-time operation, which means that you cannot make modifications at run-time. In addition, the derived class needs to have access to the features of its base class and therefore the base class cannot be fully encapsulated.

Delegation is another reusability technique. This is a black-box reusability that uses a run-time relationship between two objects. The composition by reference, see the paragraph Reusability through Object Composition, can be used to show delegation.

12

UML Newbie Guide

IOPROG/Ingmar Olsson

An Associator has either a pointer or a reference, called a delegate, to an Associatee. The class Associator is called Handle and the class Associtee is called Body. The Handle represents an abstraction and is visible to the client, while the invisible Body provides the implementation. The use of inheritance alone means that the clients code has to be recompiled whenever a concrete class used by the client is modified. The use of a combination of object composition (delegation) with inheritance means that clients code only har to be relinked with the modified code. It also helps to implement additional functionality without affecting the client, such as support for sharing objects by using reference counting or implementation of specific memory management.

13