This is part of my notes on the Unified Modelling Language(UML) that covers more inheritance features of C++ [ uml1a.html ] for notes on simple connections between classes. 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.

C++

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.

UML

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

Generalization vs Composition

Some people get a little confused at first between composition (has parts) and generalization (is a kind of). The following diagram tries to make the difference obvious: A Face is a general kind of smiling face. A Face has eyes and a mouth:



Notice that the instance of a smiling face has eyes and a mouth. It inherits them from Face.

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 diaplay 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 cmplex 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 overides f() then an object in the Derived class wil 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.



In C++, this means that all functions must be virtual to get the right effect. Here is a nice example involving a bowl of Rice Crispies that all make different sounds:



Here is the C++ code [ rice.cc ]

Abstraction and Implementation

An abstract data type (ADT) is a description of what you can do with some data, without any hint of how it is implemented on the computer. For example, we know how and why to use 'int' and mostly ignore whether it is implemented with 16, 32, or 64 bits. An abstraction lists what you can do but lets another class provide the implementations.

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.

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

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.

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. 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 Modelling 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 Generalization) <<Contents | End>>

Abbreviations