UML Object Models

Classes and Objects

The UML also allows you to show a collection of objects. Here is an example of a class (Person) and three typical objects of type Person.

Notice: the parts of the box are not: Name, Private, Public! There can be public and private attributes -- but they are usually private. There can be public and private functions(operations) -- but the are often public. Private attributes and functions have a minus sign in front of them. Public parts have a plus sign.

UML diagrams show a collection of named boxes - indicating classes or types of object. The boxes have lines connecting them called links. Each link is called an association and should model some relationship or connection between the classes. Associations also play roles in classes that are often given special names.

Templates

Special Relationships Between Classes

For more information see [ Dependency in uml1 ] in the previous notes on UML.

Composition

Use either a diamond link or an attribute for each data member! Do not show both for one member. Each diamond indicates a specific member of the class -- it is wise to add the role name.

We use the dark diamond to indicate that the class possesses the components in the sense of controlling whether they exist of not. The filled in diamond indicates that the deletion of an object may delete its components as well. The diamond indicates that the class is responsible for protecting and preserving an object of the other type. You can clarify the details by adding a stereotype like "<<creates>>", "<<uses>>", "<<deletes>>", etc. .

Aggregation

These loose connections are shown by an open or empty diamond, something like this:

 		<>--

Here is an example showing that a Restaurant will have a number of clients who are People and the the clients exist whether or not they are clients of the Restaurant:

In the above there are two diagrams. They differ in a single asterisk and this makes the difference between a realistic model of people and restaurants and an unrealistic one.

Exercise: Which is more realistic?

The other end of the Aggregation link is used to indicate whether the association can be navigated in both directions or only one:

 		<>----->	Can follow link in one direction

 		<>------	Can follow link in either direction

Linked Data Structures

 		Person * mother;

 		mother : Person

Sometimes we want to make the precise physical connection clear. To do this use a one-way aggregation:

 		<>----->

and here is part of the C++ code:

 		class Person {

 		private:

 			Person * mother;

 			Person * father;

 			vector <Person *> children;

 		...

 		};

The UML is designed so that it is possible to use Aggregation and Composition to model the linked data structures of computer science. For example the following C++ class and diagram all indicate the same classes.

 		class IntLink {

 		  public:

 			int data;

 			IntLink *next;

 		};//end IntLink

 		class IntList {

 		  public:

 			IntLink *first;

 		};//end IntList

Notice that IntLink * does not appear in the UML!

Many-to-Many and Two-way Links

          <>------        Can follow link in either direction

When the aggregation has multiplicities other than "0..1" then this implies a container of pointers is needed, not just a single pointer. So, for example:

In C++ we may need to declare an data item:

 		vector < Section * > schedule;

 		list < Section * > schedule;

 		vector < Student * > roster;

 		list < Student * > roster;

Finally when you have many-to-many two-way aggregations you may want to introduce a class to connect the two parts together and use links to explicitly create lists of the links:

 	class Student{

 		Enrolment * first_class;

 		Enrolment * last_class;

 		...

 	};

 	class Schedule{

 		Enrolment * first_on_roster;

 		Enrolment * last_on_roster;

 		...

 	};

 	class Enrolment{

 		Student * student;

 		Section * section;

 		Enrolment * next_class;

 		Enrolment * prev_class;

 		Enrolment * next_on_roster;

 		Enrolment * prev_on_roster;

 		...

 	};

Notice how one simple relations can be coded in many ways. Computer Science is about being able to choose a suitable implementation from the dozens that should work.

Generalization

 		class Derived: public Base { added_features };

In UML this relationship is called generalization. This is a relationship that is naturally expressed with a sentence like this: "Every ____ is also a _____". Here is the simple UML diagram that states that Every Student is also Person:

As drawn the diagram does not allow a Person to become a Student. In a program this would mean that the class Student would extend or inherit all the properties from Person and C++ we can implement this by writing:

	class Student : public Person { ... }

This means that

• any operation that works on a Person also works on a student
• A Student stores within it all the data that is also found in a Person.

• every Student automatically becomes a Person when they are created
• a Person can not become a Student
• a Student can not cease to be a Person.
• a Student can not change it's Person
• a Student ceases to exist at the same time as it's Person.

We say the new class is a subtype and the original class is a supertype. It should only be used when every object in the new class is automatically also an object of the class it is derived from. A subtype is a class that shares all the properties of its parent, supertype, or the class it is derived from.

Generalization vs Composition

Notice that the instance of a smiling face has eyes and a mouth. It inherits them from Face.

Inheritance

Overriding

For example, Student objects where shown above as special kinds of Person. This means that each student automatically has all the properties of a Person. It "inherits" all the attributes and all the operations from its parent type. It is also possible to show that Student has something different with the same name as Person. To show, for example, that there is an operation to display information about a Person we would add display() to the operations in Person. Instantly, Students also gain (invisibly) the ability to be displayed. But suppose we wanted to make students to behave differently - to display different information to the Person. Then we would put display() in with the operations of Student!

It is normal in object-oriented programming to find that same operation in many different classes each time with a different behavior. Thus objects know which version of the functions are to be invoked. This technique avoids much of the complex coding needed in structured programming.

Attributes can also appear in both Parent and Child. The child's attribute effectively make the Parent's version unavailable... but both are still stored in the object.

. . . . . . . . . ( end of section Generalization) <<Contents | Index>>

. . . . . . . . . ( end of section Special Relationships Between Classes) <<Contents | Index>>

Properties of Members of Classes

If it would help a project to document some special constructors do two things. First you can put

 		<<constructor>>

Second a constructor has to be a class-wide or static member function because a constructor creates a new object for the class so it can not operate on an existing object. We don't write p.Person() for example. This means that the operation is a class-wide operation and should be underlined or prefixed by a dollar sign.

Classwide or Static Parts

Other operations and attributes belong to the whole class rather than a particular object in that class. For example the number of students in a college is not an attribute of a particular student but it is an attribute of the class or set of students. Similarly, the operation of working out the GPA of a whole college is different to working out the GPA of a single student.

Similarly you sometimes need a constant that is shared across a class -- for example a double length value for pi in a mathematical class. You may also want to share a C++ variable across all objects in a class. For example in a class modeling a line of people needs pointers to the first and last people in the line. These two pointers are not present in every person in the line. They are a property of the line as a whole.

Similarly some operations belong to a class rather than to an individual... for example finding the person with the highest score in a class is not a function of one student but of the whole class. Another example would be reporting how many instances there are of a particular class of objects.

In C++ variables, constants, and operations that belong to the class and are shared by all objects of the class are declared to be "static".

In UML you show this by underlining the attribute or operation. It may appear on some displays and printouts in italic form. Some people may also use a dollar sign for this purpose.

Friendship

We can also document this with a dependency link from the friend to the class extending friendship.

. . . . . . . . . ( end of section Properties of Members of Classes) <<Contents | Index>>

Glossary

 		defined_term::=what_the_term_means.