This is part of my notes on the Unified Modelling Language(UML) that covers more features of C++ such as templates, pointers, linked lists, etc. See [ uml0.html ] for a simple introduction and [ uml.html ] for an over-view and introduction to the UML. To learn how to use Rational Rose on the csci.csusb.edu domain see [ uml3.html ] for detailed instructions. Some advanced features are covered in [ uml1b.html ] and [ uml4.html ] that includes constraints, extensions, class utilities, hints on designing classes and some common patterns.

Classes and Objects

In the UML a class of similar objects is drawn as a rectangular box. It can just contain the name of the class. It can also have two parts: the top part for the name and the second part for the attributes of the objects. It can have three parts: the name, the attributes, and the operations. Classes are often linked together with assoications as well. See [ Classes in uml1 ] for more details.

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

You have met the idea of templates in C++. The library if full of templates like vector, lists, stack, and queue. A template has a parameter that is given a particular value when the template is used:

Template	Instance
vector	vector<string>
list	list<string>

UML calls a template class a "parameterized class" and has a special notation for the class, and its instances. Here is a sketch of the STL list template, the STL list iterator, and a couple of instances list<string> and iterator<string>:



Notice that the instances depend on the templates. This means that a change in the template may force us to change the instances. As a result we can use the UML Dependency (below) link to connect the instance to its generic form.

Special Relationships Between Classes

We can use diagrams to talk about existing code and we can also use them to work out new code. There are some special relationships that hold between classes of objects in a piece of code: Dependency, Composition, Aggregation, and [ Linked Data Structures ] below. Others: Generalisation, Inheritance, and Abstraction are in [ uml1b.html ]

Dependency

It is often useful to know that one class make 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; }

We also use dependency this with a dependency link show friendship. If class Link has List for a friend -- so that List has access to the parts of a Link -- then draw a dependency arrow from List to Link and put "<<friend>>" beside it. We also use it for showing instances that <<bind>> templates.

Do not use dependency when there is a stronger relationship between to classes:

• One class is associated with another like a child and a parent for example.
• One class physically contains an object of the other type -- see Composition below
• One class refers by a iterator, name, identifier, or pointer to another -- see Aggregation below.
• One class is a special kind of another class or implements another class -- see [ uml1b.html ]

Composition

UML provides several notations that can express the physical construction of a class. The filled in diamond is often used when a class contains other objects within them as parts or components. Here are two ways of showing the same structure: A class named Period has two components: time (an array of 2 times) and days (a vector of Days).



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. Also notice that, unlike dependency, you have one "diamond" for each object that is contained in the class.

Aggregation

We can also show that a class has some parts that have an independent existence. In C++ this happens when we use pointers to refer to objects instead of storing the actual objects inside another object. An STL C++ iterator refers to an item in a collection. An object in C++ can store a pointer or an iterator. This creates a loose connection betwen two objects.

A page on the world Wide Web can use a hypertext reference to point to another resource -- deleting the page does not effect the other page. In a data base, a record can store the key of another record and so connect the records. For a real world example consider a restaurent: People may be clients of the Restaurent, but they are not part of it!

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

In the UML you should never show a C++ pointer as an attribute with an asterisk on it. In the UML and asterisk means "any number" not "is a pointer". You can use an attribute whose type is the name on the type pointed at (with no asterisk). For example to show a C++

 		Person * mother;

you can just use, in the UML,

 		mother : Person

and in some CASE systems you can specify that the attribute is "by Reference".

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

 		<>----->

and add a (0..1) multiplicity to the arrow end. The multiplicity will remind you that a pointer may have a NULL value and so point at no objects at all. So here is the UML diagram of one implementation of the Person class:



and here is part of the C++ code:

 		class Person {

 		private:

 			Person * mother;

 			Person * father;

 			vector <Person *> children;

 		...

 		};

Notice that we don't need to say "vector" in the UML.

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 class of objects, but the diagram provides extra information:

 		class IntLink {

 		  public:

 			int data;

 			IntLink *next;

 		};//end IntLink

 		class IntList {

 		  public:

 			IntLink *first;

 		};//end IntList



Notive that IntLink * does not appear in the UML!

Many-to-Many and Two-way Links

Notice that if the arrow head is missing:

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

then the C++ code must have two pointers stored. One is needed at each end of the aggregation.

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;

or

 		list < Section * > schedule;

If the aggregation is two way from Student to Section and back again (no arrow head) then we also have in the Section:

 		vector < Student * > roster;

or

 		list < Student * > roster;

Finally when you have many-to-many two-way agregations 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.

Composition or Aggregation

When in doubt about using a composition (filled diamond) or an aggregation (unfilled diamiond) don't use either. Use a bare unadorned link - an Assoication.

We use the open diamond when there is an indirect or loose linke between objects. Typically this means that one object contains some data that refers to the other object. The container has a pointer or URL of the other object. It shouldn't be used when the actual object is part od the container.

What is the precise boundary? In a composition the the container has the power of life and death of its compoents. An Agregate allows the refered parts there own lives.

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. .

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

Properties of Members of Classes

UML provides ways for documenting most of the properties of items that you list in a C++ class decoration: See Privacy, Friendship, Constructors, and [ Classwide and Static Parts ] below. In addition to the simple notations mentioned below tools will often use neat graphics, colors, or fonts instead.

Here is a quick table of stereotypes that can be used to specify particular C++ coding:

stereotype	C++
<<query>>	const
<<friend>>	friend
<<constructor>>	Classname(...)
<<destructor>>	~ Classname( )

Only use these when you need them -- to be very precise.

Privacy

Public, private, and protected members of classes are indicated by putting a plus-sign(+), minus sign(-), and hash mark(#) respectively in front of the attribute, operation, or role. In Rational Rose these appear as nothing, a padlock, and a key respecticely.

Const

The C++ const member function can be indicated by the stereotype <<query>> if you want in the UML.

Constructors

Most people don't worry about showing constructors in the UML. But if it is eseential here are some guidelines.

Constructors

You can 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>>

Since a constructor does creates a new object for the class it can not operate on an 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 and Static Parts

Some 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 modelling 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 ofthe 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 fucntion of one student but of the whole class. Another example would be reporting how many instances there are of a particular calss 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 use a dollar sign for to show that a member belongs to all the class not one object in the class.

Friendship

We sometimes need an operation that has full access to a classes private information and yet must not be applied to a single object. In C++, for example, we have "friend functions" and "friend operations". These are indicated by placing the stereotype "<<friend>>" in front of the operation in the UML class diagram.

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

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 Jim Backus and Pete Naur developed in 1960. [ BNF in glossary ] [ BNF in comp.text.Meta ] [ algol60.syntax.html ]
1. UML::=Unified Modelling Language. [ uml.html ]

2. constructor::stereotype=indicates that an operation creates a new object of its class.

3. destructor::stereotype=indicates that an operator deletes an object of its class.

4. domain::= problem_domain | application_domain.

5. problem_domain::=a collection of more or less similar problems selected for practical or theoretical reasons.

6. operations::=things that an object or a class knows how to do.

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

   Next

   Generalization and inheritance: [ uml1b.html ]

   Advanced features and hints: [ uml4.html ]

   Dynamics: [ uml2.html ]

   Using Rational Rose: [ uml3.html ]

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

Abbreviations