.Open 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
.See http://www/cs202/uml1b.html
for more advanced C++ features.
See
.See http://www/cs202/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`:

.Image uml1.gif Diagram 1

The diagram above tells us a great deal about the calss called Person:
.Set
 A Person has three $attributes: `name`, `address`, and `age`.
.Set
  A Person's name is a string and so is their address.
  A Person's `age` is an int.
.Close.Set
  Certain things can happen to a Person.  So we have these
operations or functions:
.Set
 born - which needs two string arguments
 die - which needs no arguments
 age - which returns an int and needs no arguments
.Close.Set
.Close.Set
Notice the following notations:
.As_is 		name(types) : type
.As_is 		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:
.As_is 		class Person
.As_is 		{ public:
.As_is 			string name;
.As_is 			string address;
.As_is 			int age;
.As_is 			void born(string, string);
.As_is 			void die();
.As_is 			int get_age() const;
.As_is 		};
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:
.Set
 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.
.Close.Set
These "associations" need to be put in our first
rough sketch of a model:

.Image uml.coll0.gif Boxes and Links

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:

.Image uml.coll1.jpg Links with Labels

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
.See http://www/dick/samples/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.
.Image uml04a.gif The Enrollment 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:
.As_is On the 12th of June we play SacState at Baseball.
.As_is 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:

.Image uml.game.gif Game relates Time Opponent and Sport

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

.Image usage.gif Diagram of A depends on B

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:
.As_is 	class A
.As_is 	{	public: B returns_a_B();
.As_is 		void has_a_B_argument(B);
.As_is 		void has_a_B_in_its_implementation();
.As_is 	};
.As_is 	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:
.Box
 One class has a data member of the other class's type
.See Composition
below.
 One class has a pointer or reference to the other.
.See http://www/cs202/uml1b.html#Aggregation
 One class is derived from another.
.See http://www/cs202/uml1b.html#Generalisation
 One class implements another.
.See http://www/cs202/uml1b.html#Abstraction
.Close.Box
For examples of two diagrams of the same class, with one using
dependency and the other using composition see
.See http://www/cs202/f98/clock1.gif
and
.See http://www/cs202/f98/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
.As_is 		class Period {
.As_is 			public:
.As_is 				Time time[2];
.As_is 				vector<Day> day(5);
.As_is 		};//end class Period

.Image uml.period.gif Composition of 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.
.Close Physical Links

. 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
.As_is		| - a_private_int: int            |
.As_is 		|---------------------------------|
.As_is 		| + 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:
.As_is 		<<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
.See http://www/dick/samples/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
.As_is 		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.
.See http://www/dick/samples/glossary.html#BNF

UML::=Unified Modelling Language.

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

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

domain::= $problem_domain | $application_domain.

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

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

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

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

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

. Next
Review and Reference:
.See http://www/dick/samples/uml.html

C++ in UML:
.See http://www/dick/samples/uml1b.html

Dynamics:
.See http://www/dick/samples/uml2.html

Using Rational Rose:
.See http://www/dick/samples/uml3.html

Advanced Techniques:
.See http://www/dick/samples/uml4.html
.Close Simple Object Models in UML