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 [ uml1.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 [ 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 [ Classes in uml1 ] 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 [ uml.coll1.jpg ] for examples.

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, [ 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. [ usage.gif ] For more information see [ Usage Dependency in um1 ] 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:



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:

 		<>-----

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:



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:

 		----->	One class knows about another

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

 		----->	Can follow link in one direction: singly linked

 		------	Can follow link in either direction: double linked

The one-way aggregation:

 		----->

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:

 		class IntLink {

 		   public:

 			int data;

 			IntLink *next;

 		};



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

 		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:



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



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: [ uml.dynamic.gif ] but these notes will treat the relationship as an Association and use a [ State Transition Diagrams in uml2 ] 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 [ 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:

 		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. [Down load and open [ 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:

[Rose model: [ cereal.mdl ] ] Here is the C++ code [ rice.cc ] and a Java version [ 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:

 		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:



The dashed lines indicates that its subtypes implement the abstraction. For more see [ Abstract Classes ] below.

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

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:

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

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

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



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:



The usage (dotted) arrow shows how one class uses features listed in the interface to the used class.

. . . . . . . . . ( end of section Special Kinds of 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.

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:

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

. . . . . . . . . ( 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 John Backus and Pete Naur developed in 1960. [ BNF in glossary ] [ BNF in comp.text.Meta ] [ algol60.syntax.html ]
1. 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.

2. UML::=Unified Modeling Language. [ uml.html ]

3. 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.
4. abstraction::=the process or result of leaving out details.
5. application_domain::=a collection of more or less similar solutions.
6. association::=a connection between objects. Indicated by drawing a line joining the classes.
7. attributes::=values that an object or class is responsible for maintaining.

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

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

10. domain::= problem_domain | application_domain.

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

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

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

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

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

16. 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: [ uml4.html ]

    Dynamics: [ uml2.html ]

    Using Rational Rose: [ uml3.html ]

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