Simple Object Models in the UML

These notes show how the Unified Modelling Language(UML) can be used to document and design simple C++ classes. For more information see [ uml1b.html ] for more advanced C++ features. See [ uml.html ] for a more notes on other features of the UML.

Dr. Botting's site (Next below) is a comprehensive resource for experienced users of the UML.

Drawing a Class

Here is a diagram that shows a class called Person:



The diagram above tells us a great deal about the calss called Person:


A Person has three attributes: name, address, and age.
• A Person's name is a string and so is their address.
  A Person's age is an int.
• Certain things can happen to a Person. So we have these operations or functions:
  • born - which needs two string arguments
  • die - which needs no arguments
  • age - which returns an int and needs no arguments
Notice the following notations:

 		name(types) : type

 		name : type

for declaring the types of operations and attributes. Do not use the C++ notation ( type name ) in UML diagrams by mistake.

Translating the diagram into C++ gives:

 		class Person

 		{ public:

 			string name;

 			string address;

 			int age;

 			void born(string, string);

 			void die();

 			int get_age() const;

 		};

Notice that we do not use void in UML.

The Person class was documented by drawing a box with three compartments: one for the name, one for the data its objects store, and one for the operations. Do not make the mistake of drawing a box for every attribute and operation. All attributes are in one compartment and all operations in the next one. The UML defines only three compartments for classes. The compartments for the operations and attributes can be left out. We can (in theory) even add new ones if we really need them for some purpose. However the UML does not define the purpose and meaning of any new compartments. So other people will not understand what these new compartments mean.

Many Types of Object

Suppose that we were modelling this campus then we would be interested in things like: Students, Teachers, Courses, Sections, and so on. This is a lot of different classes so in the UML we omit the details of the operations and attributes and put only their name in a box. We then connect up the boxes to show the various relationships between the objects. These are shown as line connecting the boxes that are called links or associations.

If we were developing software for a small college we would need to keep track of relationships like these:

• A Teacher teaches a number of sections.
• A Section is for a particular Course.
• A Section is taught by a particular teacher.
• A Student is enrolled in a class
• and so on.
These "associations" need to be put in our first rough sketch of a model:



The diagram shows a collection of named boxes - indicating classes or types of object. The boxes have lines connecting them called links. In the above each link is called an association. The next step in filling out the sketch of a program by adding names and numbers to the associations in the diagram:



The labels in the middle of the links are the names of the association between the classes at the ends. An example is the association of "Enrollment" between Student and Section. The name of the association is written near the middle of the link.

The names written at an end of an association are called 'role' names. For example, on the link between "Person" and "Teacher" there is a rolename of "teacher". Notice that the rolename is closest to the "Teacher" box and is the same word with different capitalization to the box. A more typical association has both an association name and roles. For example the link between Student and Major is an association named "Declaration". A Declaration shows that a student is "majoring_in" a Department. The association's name is "Declaration" and one of its roles is the "majoring_in" role. UML looks at roles from the association's (or link's) point of view.

Similarly: the diagram shows that a Room is in a Building and a Building has Rooms and a Period is between two times.

The numbers and asterisks next to the ends of the links are called multiplicities. They show how many object play a role in a relationship. For example, a person is either one teacher or is no teacher (0..1). But a teacher can teach any number of Sections, including none (0..*). A Section however is taught by exactly one Teacher, and a Teacher is exactly one Person. Again a Student may declare a single major(1) or may not have declared one(0). However at any time there can be any number of Students who have declared a major in a particular Department.

Modelling Concepts

Before you write any code you can get a good start on the structure of the code (what classes, variables, and functions are needed) by making a model of the ideas or concepts involved. You start with a model of the "obvious" classes of objects as above. However you can go further and model quite complex and subtle ideas as types of object as well.

For example the association between Student and Section is a many-to-many relation: A student can enroll in many Sections and a Section can have any number of Students enrolled in it. Such many-to-many relations are often worth studying in detail. The UML shows this by attaching a box to the link. See [ uml04b.gif ] of how the UML can document that a class is responsible for an association.

These notes will show that Enrollments themselves are interesting objects and so model Enrollments as another class. The Enrollment class has objects that will be responsible for tracking the enrollment status of a student in a class.

The test for whether these new concepts( boxes) should be classes in our program is to see if they have some special responsibilities in addition to just connecting two other objects. For example, a connection Enrollment can help the class scan across all the students who are enrolled in the class, and (vice versa) help a student list the classes they are enrolled in. But a pair of normal associations can handle this quite well. For us to continue treating an Enrollment as a good class we need some other responsibilities. For example, an Enrollment can be held responsible for storing a student's grade since without an enrollment there can be no grade. It can also be made responsible for noting adds and drops.

In many problems it is worth thinking about a relation between three or more objects as if it was itself an object. For example suppose the Athletic Dept. of our College hires us to work on a program for scheduling games then we would notice that our client used statements like this:

 On the 12th of June we play SacState at Baseball.

 On the 17th of July we play WassamattaU at Soccer.

The general form is "On <some time> we play <an opponent> at <a Sport>". This a relation between three things: a Time, an Opponent, and a Sport. The classical UML diagram of this relation would be:



You can now think about the attributes and operations that might belong to a Game. In other words we look for things that a Game must know, and for things that a game can do for us.

We would need to do a lot of thinking and diagramming before we get a model that we could use to generate code. In these notes you will see some of the special things that we might look for when drawing these diagrams and so thinking about our problems and solutions.

Physical Links

There are some special relationships that hold between pieces of code. The conceptual links mentioned above are useful for analysing a problem. The notations in this section are most useful for documenting solutions to problems in terms of classes of objects.

Dependency

It is often useful to know that one class makes use of another class in some way or other. This is shown as a dotted arrow from the client class to the class that provides the service.



Only one arrow is drawn between A and B however many "usages" there are.

He is a simple rule for when a dependency occurs. If the code for one class contains the name of another class in the diagram, and no other connection exists in the diagram between them then there should be a dashed dependency arrow from the first to the second class. For example the class A below uses class B in several ways:

 	class A

 	{	public: B returns_a_B();

 		void has_a_B_argument(B);

 		void has_a_B_in_its_implementation();

 	};

 	A::void has_a_B_in_its_implementation(){ B b; }

is shown like this:

Here are the cases when you do not use a dotted arrow but something else:

---

1. One class has a data member of the other class's type [ Composition ] below.
2. One class has a pointer or reference to the other. [ Aggregation in uml1b ]
3. One class is derived from another. [ Generalisation in uml1b ]
4. One class implements another. [ Abstraction in uml1b ]

---

For examples of two diagrams of the same class, with one using dependency and the other using composition see [ clock1.gif ] and [ clock2.gif ] which are two acceptable models of the Clock class using the UML.

There is little risk in simplifying a complex diagram by omitting the dependencies caused by attributes that are shown in the diagram.

Composition

In C++ we can declare a struct that is a collection of parts. C++ classes have data members that are part of the state of the whole object. In more abstract terms we would say that a bird has wings and legs as parts. Similarly, a web page is composed of headings, paragraphs, and so one. In this kind of physical containment we can use the composition link to connect the whole to each of its parts.

UML provides several notations to show this. Here is the code of the implementation of a time Period in our college model

 		class Period {

 			public:

 				Time time[2];

 				vector<Day> day(5);

 		};//end class Period



In the UML we use the dark diamond to indicate that the class possesses the components. This is the kind of ownership that holds between an automobile and its four wheels. When we destroy the auto the wheels go with it.

When we code a simple composition like this a multiplicity of one indicates a simple data member in the C++ class. A fixed multiplicity suggests an array. A range of multiplicities or any asterisk suggests a more complex data structure such as a vector, list, or set. If the order is important, then the constraint "{ordered}" should be put at the end of the link. You can indicate that a vector is used by the stereotype "<<vector>>" in work for CS classes at CSUSB.

Note that although we used a dark diamond to indicate that an item is stored within another piece of data that the "dark diamond" has a wider use: It indicates a class of objects that have some (permanent or temporary) responsibility for the existence of at least one object at the other end. Thus a filled in diamond means that the class with the diamond will either create or delete the objects at the other end. If an item of data is stored inside an object then the creation and deletion of the whole object automatically insures that the parts are also created and/or deleted. This is the reason why we should use the filled diamond to show that one object contains another one.

. . . . . . . . . ( end of section Physical Links) <<Contents | End>>

Privacy

Public and private members of classes are indicated by putting a plus-sign for public and a minus sign for private attributes and operations like this

		| - a_private_int: int            |

 		|---------------------------------|

 		| + a_public_operation(...) : ...   |

Constructors

You can also indicate that an operation is a constructor - in UML constructors don't have to be named the same as their class. This is done by putting this above the function:

 		<<constructor>>

This notation with French quotation marks: <<....>> . It is called a stereotype. When a stereotype is added to something in a UML diagram its meaning becomes more specialized. In this case an the operation is forced to be an operation that creates and initializes a new object of the right type.

Notice that a constructor should not be shown as "returning" a type. It does not. It is called by the "new" command and used in declarations to implicitly create new objects.

A Partial Model of a College

Normally all the different models discussed above would be part of one big diagram summarizing all the classes and their relationships. There is a sample of how part of this might look in [ uml4.jpg ] By the way this model doesn't fit any real college or any project you may do. It is constructed as an example of modelling techniques rather than as a model of any know college.

Glossary

Note. In this glossary a definition is written like this

 		defined_term::=what_the_term_means.

When there are several alternative meanings they are separated by a vertical bar symbol: "|". This is an informal extension of the notation John Backus and Pete Naur developed in 1960. [ BNF in glossary ]
1. UML::=Unified Modelling Language.

2. application_domain::=a collection of more or less similar solutions.
3. association::=a connection between objects. Indicated by drawing a line joining the classes.
4. attributes::=values that an object or class is responsible for maintaining.

5. constraint::=a property that must be true of any implementation of a model.

6. domain::= problem_domain | application_domain.

7. link::=a line connecting two boxes that in the UML indicates a relationship or association between the two boxes.

8. problem_domain::=a collection of more or less similar problems. A person can select the make of this collection for practical or theoretical reasons.

9. operations::=things that an object in a class knows how to do.

10. role::=the part that an association plays in a class documented by putting a name near one end of the link.

11. stereotype::UML=a special note looking like this: <<example>> that adds to the meaning of a UML diagram.

    Next

    Review and Reference: [ uml.html ]

    C++ in UML: [ uml1b.html ]

    Dynamics: [ uml2.html ]

    Using Rational Rose: [ uml3.html ]

    Advanced Techniques: [ uml4.html ]

. . . . . . . . . ( end of section Simple Object Models in UML) <<Contents | End>>