.Open UML Object Models
This is part of my notes on the Unified Modeling Language($UML) that covers
more features of C++ such as pointers, linked lists, etc.  See
.See http://www/dick/samples/uml1.html
for a simple introduction and
.See http://www/dick/samples/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
.See http://www/cs202/uml3.html
for detailed instructions.
Some advanced features are covered in
.See http://www/dick/samples/uml4.html
that includes constraints, extensions, class utilities, hints on
designing classes and some common patterns.

. Classes
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.  See
.See htpp://www/cs202/uml1.html#Classes
for more details.

. Associations
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.
See
.See http://www/cs202/uml.coll1.jpg
for examples.

.Open 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, 
.See Linked Data Structures
, $Generalization, $Inheritance, $Discriminants, $Polymorphism, and $Abstraction.  
. 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. 
.See http://www/cs202/usage.gif
For more information see
.See http://www/cs202/um1.html#Usage Dependency
in the previous notes on UML.
. Composition
$UML provides several notations that can express the physical
construction of a class.  The filled in diamond is often used when
a class contain other objects within them as parts or components.
Here are two examples:

.Image uml.period.gif Composition of Period

We can 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.  For this reason is OK to have a diagram where
one class is apparently "parts" of two other classes.  This actually
means that at different times either one or the other class has
a "parental" responsibility for the other -- of protecting and preserving
it.  You can clarify the details by adding a $stereotype like
"<<creates>>", "<<uses>>", "<<deletes>>", etc. .
. Aggregation
In older UMLs we used an `aggregation` to indicate a loose
form of `has`:
.As_is 		<>-----
An example might be a the way
that an Army has Warriors - the Army can be demobbed but the People
playing the part of Warriors continue to exist. In the computer
world 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.
Similarly an object in C++ can store
the address of another object and so link them together.

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:

.Image uml.association.gif Association: Restaurant has Clients

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.


UML gurus now recommend using a simple association instead.  The additional
diamond shape does not change the meaning of the diagram in any real way.
. Associations
Associations are a powerful, simple, and useful connection between classes:
.As_is 		----->	One class knows about another
.As_is 		------	Each class knows about the other.
The ends can have multiplicities (1, 0..1, 1..*, 28..31, *) and role names.

$TBA
. Linked Data Structures
An $Association is often implemented using pointers or links.

A linked data structure can be documented using associations.
The arrow
indicates whether the association can be navigated in both directions
or only one:
.As_is 		----->	Can follow link in one direction: singly linked
.As_is 		------	Can follow link in either direction: double linked

The one-way aggregation:
.As_is 		----->
is a useful way to document a pointer or reference in a C++ program.  If
you do this then it is wise to also add a (0..1) multiplicity to the
arrow end to remind you that a pointer may have a NULL value and so point
at no objects at all.

The $UML is designed so that it is possible to use $Association and
$Composition to model the linked data structures of computer
science.  For example the following C++ struct and diagram all indicate
the same class of objects, but the diagram provides extra information:
.As_is 		class IntLink {
.As_is 		   public:
.As_is 			int data;
.As_is 			IntLink *next;
.As_is 		};
.Image uml.link.gif UML diagram of IntLink

(The plus sign above indicates a public item, see $Privacy below)

Similarly containers of pointers are shown as associations with multiplicities
other than 0..1.

More $TBA.
. Generalization
In C++ we can construct a new class that is derived from another
class:
.As_is 		class Derived: public Base { added_features };
This means that the new Derived class extends the property of the old  Base class.
Each object of Derived can do anything that an object of Base can.  Each Derived
object holds all the data that a Base object does.  Derived classes can redefine
and extended the data and operations of the Base class.


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`:

.Image uml.gen2.gif Diagram 2:Student specialized from 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:
.As_is	class Student : public Person { ... }

This means that 
.Set
 any operation that
works on a Person also works on a student
 A Student stores withing 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.
.Close.Set
Generalization
is commonest in the more formal domains of geometry (see $Abstraction below)
mathematics, and legislation.

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.

. Inheritance and Overriding
Logically generalization means that anything that can be
done to or by a Person can also be done to or by
a Student.
We say that "Student inherits from Person".  In the UML this is indicated by
default -- when ever the student doesn't list a public feature in a child class
it can inherit the parent's version.

However a Student may sometimes
react with different behavior than the more general
Person does.  This is called `over-riding`.

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.

. Discriminants
There is another variation of $generalization that might be used in a $domain
where the gender of a Person makes a difference to what they do, and where
the gender is a fixed property of the Person:

.Image uml.gender.gif Person as Male or Female

The word `gender` in the above diagram is called a $discriminant.
The diagram, by the way, is only suitable for certain domains.

In a $domain were an object can start out as a Person and the become
a Student, or where an object can start out as a Student and later
cease to be a Student we would want some kind of $dynamic connection
between Person and Student.  $UML does provide a standard way to
document this:
.See http://www/dick/samples/uml.dynamic.gif
but these notes will treat the relationship as an $Association and use a
.See http://www/dick/samples/uml2.html#State Transition Diagrams
to document the possible changes of behavior.

You may feel that even so there is something that is in common between
Teachers, Students, and People and feel that it is important to show
this in a diagram.  If so see 
.See http://www/dick/samples/uml.dynamic.gif
or else $Abstraction and/or $Interfaces below.
. Polymorphism
In the UML it is assumed that if an operation is applied to an object
and there
are several alternative classes that have the operation defined then
the object to which the operation is applied always determines the
operation that is executed.  This is even true if the access to the
object is via a pointer in C++ using syntax like this:
.As_is 		pointer->function(arguments).

For example if there is a Base class with
a function f() and a Derived class that overrides f() then an object
in the Derived class will execute Derived's f, and an object in the Base
class executes the Base f.  This is true even if the access is via a
pointer to the object and if the variable holding the pointer is declared
to be of the Base type.
.Image http://www.csci.csusb.edu/dick/cs320/handouts/poly.gif poly.gif
[Down load and open
.See http://www.csci.csusb.edu/dick/cs320/handouts/poly.mdl
in Rational Rose].

In C++ this means that all functions tend to be `virtual`.  Here is a nice
example involving a bowl of Rice Crispies that  all make different sounds:

.Image http://www.csci.csusb.edu/dick/cs320/handouts/cereal.gif cereal.gif
[Rose model:
.See http://www.csci.csusb.edu/dick/cs320/handouts/cereal.mdl
]
Here is the C++ code
.See http://www.csci.csusb.edu/dick/examples/rice.cc
and a Java version
.See http://ftp.csci.csusb.edu/public/faculty/dick/Crispy.java
. Abstraction
You may have already met the idea of an Abstract Data Type(ADT). If
not see $ADT in the glossary.

In C++ An abstract class has at least one function declared like this:
.As_is 		virtual type name(arguments)=0;
Such a function is said to be "abstract".
The "=0;" means that this function will be defined in the classes
derived from this class.  This
in turn implies that we can not have any objects declared directly
as being in an abstract type - because there operations do not exist in
that type.   However we can derive classes from an abstract class and
declare objects in `these` classes.  The classic example is that
of a geometric figure or shape:  The idea of shape exists, but all objects
are defined as having a particular shape.  Here is the UML diagram:

.Image uml.shape.gif A Abstract Shape implemented by Circle, Triangle and Rectangle

The dashed lines indicates that its subtypes implement the abstraction.
For more see
.See Abstract Classes
below.
.Close Special Relationships Between Classes
.Open Special Kinds of Classes
. Templates
You have met the idea of templates in C++.  $UML calls a template class a
"parametrized class" and has a special notation for the class, and its
instances:
for them:
.Image uml.template.gif The list Template
. Abstract Classes
An abstract class defines operations that can be called and attributes and relationships
with other classes - but you are not allowed to declare objects of that type.
Instead you must declare objects of a subtype.  We use this idea when several concrete
classes share a common abstraction but are otherwise different, and we don't want any
ambiguous "abstract" objects in our code.
An abstract class is shown by adding a tag
.As_is 		{abstract}
in its $UML diagram.
The "{...}" indicates a tag that qualifies the meaning of the
tagged part of the $UML diagram.  In some cases, abstraction is indicated by using
italic text.  Abstractions are connected to particular
concrete classes by dotted lines and the generalization triangle
(See $Abstraction above).
. Interfaces
An interface is an important computer science and
software engineering idea.  Some languages (Java for example) have
an "interface" keyword.  An interface defines a software wall socket or jack.
Another piece of software can "plug" into the interface.
An interface defines how two parts of a program communicate
with each other.  It declares a set of operations that a class provides to the
other classes in a program.  
Interfaces are an idea that can be described in most languages including C++.

In C++ interface is a abstract class that has nothing but
function headers/prototypes.  The clients of an interface call the
functions.  Various classes implement the interface by defining all
the functions in the interface.  In C++ we use inheritance to
indicate this and in Java the keyword "implements".
In the $UML an interface is shown as a class with the following
$stereotype written on it:
.As_is 		<<interface>>
There is a special $UML notation for showing that a class
implements an interface.  For example, we can document an Animate interface
defining things that happen to Animate objects.  We can then specify that
People, Student, and Teacher, all implement this interface:

.Image uml.interface.gif An Interface

There is also a notation for showing that a class is a client of an
interface.  For example we might show that a class of Registrars use
the 'Animate' interface of a student -- probably to add and delete Student
records:

.Image uml.client.gif A Client using an interface

The usage (dotted) arrow shows how one class uses features listed
in the interface to the used class.
.Close Special Kinds of Classes

.Open 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 
.See Classwide and Static Parts
below.  In addition to the simple notations mentioned below tools
will often use neat graphics, colors, or fonts instead.
. 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 respectively.
. 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>>
. 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.
. 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 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.

.Close Properties of Members of Classes
. 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
.See http://www/dick/samples/comp.text.Meta.html#BNF
.See http://www/dick/samples/algol60.syntax.html

ADT::="Abstract Data Type".  A collection of operations that operate objects with an unknown or hidden structure.  An ADT tells you what you can do to the data objects but not how they are stored or how their code is implemented.

UML::=Unified Modeling Language.
.See http://www/cs202/uml.html

abstract::$stereotype=indicates that a class defines an $abstraction so that no objects of this type exist except as objects of the specific subtypes of this type.
abstraction::=the process or result of leaving out details.
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.

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

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

domain::= $problem_domain | $application_domain.

generalization::=the process or the result of making something more general.

interface::$stereotype=indicates that a type is an abstract data type consisting solely of operation prototypes. An interface can implemented by one or more other types and can be used by one or more types.

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

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

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

subtype::=One class is a subtype of another class if all the operations
of the second class of object also apply to objects of the first type - perhaps in a different way.
. Next
Advanced features and hints:
.See http://www/dick/samples/uml4.html

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

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

.Close UML Object Models