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.
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
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.
Notice that the instance of a smiling face has eyes and a mouth. It inherits them from Face.
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.
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.
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 ]
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}
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
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.
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 ]
Dynamics: [ uml2.html ]
Using Rational Rose: [ uml3.html ]
. . . . . . . . . ( end of section Generalization) <<Contents | End>>