Object-Oriented

Analysis and
Design
4 ADVANCED OBJECT
MODELING

Source: OBJECT-ORIENTED
MODELING A N D DESIGN
James Rumbaugh, Michael Blaha,
William Premerlani, Frederick Eddy,
William Lorensen

PAUL VOUGNY - EPITA 2008

 1. AGGREGATION

✘Aggregation is a strong form of association in which an aggregate object is made

of components. Components are part of the aggregate.

✘Aggregation is inherently transitive; an aggregate has parts, which may in turn

have parts.

✘ Recursive aggregation is common.

 AGGREGATION versus ASSOCIATION

✘Aggregation is a special form of association, not an independent concept.

Aggregation adds semantic connotations in certain cases.

✘ If two objects are tightly bound by a part-whole relationship, it is an

aggregation.

✘If the two objects are usually considered as independent, even though they may
often be linked, it is an association.

Some tests include:

❤ Would you use the phrase part of?

❤ Are some operations on the whole automatically applied to its parts?

❤ Are some attributes values propagated from the whole to all or some parts?

❤ Is there an intrinsic asymmetry to the association, where one object class

is subordinate to the other?
Company Division Department

Works for

Person

Aggregation
and
association
 AGGREGATION versus GENERALIZATION

✘Aggregation is not the same thing as generalization. Aggregation relates

instances. Two distinct objects are involved; one of them is a part of the other.

✘Generalization relates classes and is a way of structuring the description of a

single object. Both superclass and subclass refer to properties of a single object.
With generalization, an object is simultaneously an instance of the superclass and an
instance of the subclass.

✘ Aggregation is often called a- part-of relationship;

✘ Generalization is often called a - k i n d - o f or i s - a relationship.

 Lamp

Fluorescent Incendescent
Base Cover Switch Wiring
Lamp Lamp

Twist
Ballast Starter Socket
mount
Aggregation
and
generalization
✘ Aggregation is sometimes called an and-relationship
and generalization an or-relationship.

✘ A lamp is made of a base and a cover and a switch and wiring and so on.

✘ A lamp is a fluorescent lamp or an incandescent lamp.

RECURSIVE AGGREGATES

✘ Aggregation can be fixed, variable, or recursive.

✘A variable aggregate has a finite number of levels, but the number of parts may
vary.

✘A recursive aggregate contains, directly or indirectly, an instance of the same kind

of aggregate; the number of potential levels is unlimited.

Program

Recursive
Block
Aggregate

Compound Simple
statement statement
 PROPAGATION OF OPERATIONS
Propagation (also called triggering) is the automatic application of an operation to
a network of objects when the operation is applied to some starting object. For
example, moving an aggregate moves its parts; the move operation propagates to
the parts. Propagation of operations to parts is often a good indicator of
aggregation.

Person Document Paragraph Character

copy copy
Owns
copy copy copy

Most of the approaches present an all-or-nothing option:

copy an entire network with deep copy, or copy the starting
object and none of the related objects with shallow copy.
Propagation
of operations The propagation behavior is bound to an association
(or aggregation), direction, and operation.

The arrow indicates the direction of propagation.

 2. ABSTRACT CLASSES
-An abstract class is a class that has no direct instances but whose descendent
classes have direct instances.

- A concrete class is a class that is instantiable; that is, it can have direct
instances.

-A concrete class may have abstract subclasses (but they in turn must have
concrete descendants).

-A concrete class may be a leaf class in the inheritance tree; only concrete classes
may be leaf classes insubclass
the inheritance tree.
subclass 1+ Class
1+
Has subclasses Object model
Has subclasses defining
abstract and
concrete class
Concrete Abstract
Instance
Has direct class class superclass
instances

superclass The figure summarizes

Non-leaf
Leaf class the definition of abstract
concrete class
and concrete class.
 All the occupations shown Class Employee is an exemple of
here are concrete classes abstract class. All employees must be
either hourly, salaried, or exempt.

Worker

Abstract class
and abstract
operation

Candlestick
Butcher Baker
Maker ...
Employee
year-to-date earnings
compute pay {abstract}
Concrete
classes

Hourly Salaried Exempt

Employee Employee Employee
hourly rate weekly rate monthly rate
overtime rate compute pay compute pay
compute pay
✘Abstract classes organize features common to several classes. It is often useful to
create an abstract superclass to encapsulate classes that participate in the same
association or aggregation.

✘Abstract classes are frequently used to define methods to be inherited by

subclasses. On the other hand, an abstract can define the protocol for an operation
without supplying a corresponding method. We call this an abstract operation.

✘A method is the actual implementation of an operation. An abstract operation

defines the form of an operation for which each concrete subclass must provide its
own implentation. A concrete class may not constain abstract operations because
objects of the concrete class would have undefined opererations.

✘The origin class defines the protocol of the feature, that is the type of an attribute
or the number and type of arguments and result type for operations, as well as the
semantic intent. Descendent classes can refine the protocol by further restricting the
types or by overriding the initialization or method code. Descendent classes may
not expand or change the protocol.

✘A concrete class can usually be refined into several subclasses, making it abstract.
Conversely, an abstract class may become concrete in an application in which the
difference among its subclasses is unimportant.
 3. GENERALIZATION AS EXTENSION A N D RESTRICTION

✘An instance of a class is an instance of all ancestors of the class. This is part of the
definition of generalization. Therefore all ancestor class features must apply to the
subclass instances.

✘A descendent class cannot omit or suppress an ancestor attribute because then it

would not truly be an ancestor instance. Similary operations on an ancestor class
must apply to all descendent classes.

✘A subclass may reimplement an operation for reasons of efficiency but cannot

change the external protocol.

✘ A subclass may add new features. This called extension.

✘ A subclass may also constrain ancestor attributes. This is called restriction

because it restricts the values that instances can assume.
✘For example, a circle is an ellipse whose major and minor axes are equal. Arbitrary
changes to the attribute values of a restricted subclass may cause it to violate the
constraints, such that the result no longer belongs to the orignal subclass. This is
not a problem for the perspective of the superclass because the result is still a valid
superclass instance. For example, a circle that is scaled unequally in the x and y
dimensions remains an ellipse but is no longer a circle. Class Ellipse is closed under
the scaling operation, but Circle is not.

✘ Inherited features can be renamed in a restriction.

✘Restriction implies that a subclass may not inherit all the operations of its
ancestors. Thus, the Circle class must suppress the unequal scale operation. On the
other hand, an object declared to be an ellipse is not restricted to remain a circle
even if its major and minor axes happen to be temporarily equal.

y
x
 OVERRIDING OPERATIONS

✘ Overriding for extension

The new operation is the same as the inherited operation, except it adds some
behavior, usually affecting new attributes of the subclass.

✘ Overriding for restriction

The new operation restricts the protocol, such as tightening the types of
arguments.

✘ Overriding for optimization

The new method must have the same external protocol and results as the old one,
but its internal representation and algorithm may differ completely.

✘ Overriding for convenience

The new class is made a subclass of existing class and overrides the methods that
are inconvenient.
We propose the following semantic rules for inheritance. Adherence to these rules
will make a software easier to understand, easier to extend, and less prone to errors
of oversight:

❤ All query operations (operations that read, but do not change, attribute values)
are inherited by all subclasses.

❤ All update operations (operations that change attributes values) are inherited
across all extensions.

❤ Update operations that change constrained attributes or associations are blocked

across a restriction. For example, the scale_x operation is permitted for class
Ellipse, must be blocked for subclass Circle.

❤ Operations may not be overridden to make them behave differently (in their
externally-visible manifestations) from inherited operations. All methods that
implement an operation must have the same protocol.

❤ Inherited operations can be refined by adding additional behavior.

4. MULTIPLE INHERITANCE

✘Multiple inheritance permits a class to have more than one superclass and to
inherit features from all parents. This permits mixing of information from two or
more sources.

✘It brings object modeling closer to the way people think. The disadvantage is a
loss of conceptual and implementation simplicity.

DEFINITION

✘ A class with more than one superclass is called a join class.

✘Conflict among parallel definitions create ambiguities that must be resolved in

implementations. In practise, such conflicts should be avoided or explicitly resolved
to avoid ambiguities or misunderstandings, even if a particular language provides
a priority rule for resolving conflicts.
 Vehicle

Multiple
inheritance
overlapping
LandVehicle WaterVehicle from
overlapping
subclasses
classes

disjoint
Car AmphibiousVehicle Boat
subclasses

join class

The generalization subclasses may or may not be disjoint. For example,

LandVehicle and WaterVehicle overlap because some vehicles travel on both land
and water.

A hollow triangle indicates disjoint subclasses; a solid triangle indicates

overlapping subclasses.
 Employee
pay status pension status

Hourly Salaried Exempt Vested Unvested disjoint

Employee Employee Employee Employee subclasses
Employee

Multiple
Vested
inheritance
Hourly join class from disjoint
Employee
classes

HourlyEmployee, SalariedEmployee, and ExemptEmployee are disjoint; each

employee must belong to exactly one of these.

A class can multiply inherit from distinct generalization or from different classes
within an overlapping generalization but never from two classes in the same disjoint
generalization.

- generalization: conceptual relationship

- inheritance: language mechanism
 ACCIDENTAL MULTIPLE INHERITANCE

An instance of a join class is inherently an instance of all the ancestors

of the join class.

For example, an instructor is This an example of "accidental" multiple

inherently both faculty and student.
inheritance, in which one instance happens
But what about a Harvard Professor
taking classes at MIT? to participate in two overlapping classes.

University
Person
Member

Workaround for
accidental Faculty Student Staff
multiple
inheritance

Instructor
 WORKAROUNDS

Dealing with lack of multiple inheritance is really an implentation issue, but early
restructuring of model is often the easiest way to work around its absence.

✘Delegation is an implentation mechanism by which an object forwards an

operation to another object for execution.

✘ Delegation using aggregation of roles

A superclass with multiple independent generalizations can be recast as an
aggregate in which each component replaces a generalization.

✘ Inherit the most important class and delegate the rest

The join class is treated as an aggregation of the remaining superclass and their
operations are delegated as in the previous alternative.

✘ Nested generalization
Factor on one generalization first, then the other. This approach multiplies out all
possible combinations. This preserves inheritance but duplicates declarations
and code and violates the spirit of object-oriented programming.
 Employee

Employee Employee
Payroll Pension

pay status pension status

Hourly Salaried Exempt Vested Unvested

Employee Employee Employee Employee
Employee

Multiple
inheritance
using figure 1
delegation
 Employee
Employee
Pension

pay status pension status

Hourly Salaried Exempt Vested Unvested

Employee Employee Employee Employee
Employee

Multiple
inheritance using
figure 2
inheritance and
delegation
 Employee

pay status

Hourly Salaried Exempt

Employee Employee Employee

pension status pension status pension status

Hourly Hourly Salaried Salaried Exempt Exempt

Vested Unvested Vested Unvested Vested Unvested
Employee Employee Employee Employee Employee Employee

Multiple
inheritance
figure 3
using nested
generalization
Any of these workarounds can be made to work, but all compromise logical
structure and maintainability. Some issues to consider when selecting the best
workaround are:

❤ If a subclass has several superclasses, all of equal importance, it may be best to

use delegation (figure 1) and preserve symmetry in the model.

❤ If one superclass clearly dominates and the others are less important,
implementing multiple inheritance via single inheritance and delegation may
be best (figure 2).

❤ If the number of combinations is small, consider nested generalization

(figure 3). If the number of combination is large, avoid it.

❤ If one superclass has significantly more features than the other superclasses or
one superclass clearly is the performance bottleneck, preserve inheritance
through this path (figure 2 or figure 3).

❤ If you choose to use nested generalization (figure 3), factor on the most
important criterion first, the next most important second, and so forth.

❤ Try to avoid nested generalization (figure 3) if large quantities of code must be

duplicated.

❤ Consider the importance of maintaining strict identity.

Only nested generalization (figure 3) preserves this.
5. METADATA
Metadata is data that describes other data. For example, the definition of a class is
metadata. Models are inherently metadata, since they describe the things being
modeled (rather than being the things).

Thus a data table may store the fact that the capital of Japan is Tokyo.

A metatable would store the fact that a country has a capital city.

PATTERNS A N D METADATA
(Person)
A class describes a set of object
instances of a given form. Joe Smith
Instantiation relates a class to its age = 39
Person weight =
instances. In a broader sense, name Notation for
158
any pattern describes examples age (Person)
of the pattern; the relationship weight instantiation
between pattern and example Mary Wilson
can be regarded as an extension age = 27
of instantiation. weight =
121
Real-world things may be metadata.

pattern object

CarModel Car
It is better to consider the model serial #
CarModel object as a year color
pattern, a piece of metadata, base price options
that describe Car objects.
Manufacturer Owner

Company Person
Pattern and

individuals
 CLASS DESCRIPTORS

Classes can also be considered as objects, but they are meta-objects and not real-
world objects. Class descriptor objects have features, and they in turn have their
own classes, which are called metaclasses.

A class attribute describes a value common to

an entire class of objects, rather than data Window
peculiar to each instance. Class attributes are size : Rectangle
useful for storing default information for creating visibility : Boolean
new objects or summary information about $all_windows : set[Window]
instances of the class. $visible_windows : set[Window]
$default_size : Rectangle
$maximum_size : Rectangle
A class operation is an operation on the class display
itself. The most common kind of class operations $new_Window
are operations to create new class instances. $get_highest_priority_Window
Operations to creates instances must be class
operations because the instance being operated
on does not initially exist. A query that Class
provides summary information for instances in with class
a class is also a class operation. Operations on features
class structure, such as scanning the list of
attributes or methods, are class operations.
6. CANDIDATE KEYS

The best approach for n-ary associations is to specify candidate keys.

A candidate key is a minimal set of attributes that uniquely identifies an object or

link. It means that we cannot discard an attribute from the candidate key and still
distinguish all object and liniks.

A class or association may have one or more candidate keys, each of which may
have different combinations and numbers of attributes.

The object ID is always a candidate key for a class. One or more combinations of
related objects are candidate keys for associations.

Each candidate key constrains the instances in a class or the multiplicity of an

association. Multiplicity and candidate keys have nearly the same expressive power
for binary associations.
 Many-to-many One-to-many Optional-to-one
association association association

Person Person Country

Owns_stock Works_for Has_capital

Company Company City

{Candidate key: {Candidate key: {Candidate keys:

(person, company)} (person)} (country)
(city)}

Comparison of
multiplicity with
candidate keys
for binary
associations
 Project Language

Person
Ternary
associations

{Candidate key: (project, person, language)}

Project Person Language

C A D program Mary C
control Susan Ada
software Mike C
C + + compiler Bob assembler
CAD Mike C
program Mike assembler
C A D program
C A D program
We deduce the candidate key by considering all the possibilities.
 Student University

Professor
Ternary
associations

{Candidate key: (student, university)}

Student Professor University

Mary Prof Weaver SUNY

Mary Prof Rumrow RPI
Susan Prof Weaver RPI
Prof Weaver SUNY
Susan Prof Shapiro Oxfo
Bob rd

Student+University may be a candidate key, since no links share the same values.
Student+Professor+University is not a candidate key, because it is not a
minimal set of attributes.
7. CONSTRAINTS

DEFINITION
Constraints are functional relationship between entities of an object model. The
term entity includes objects, classes, attributes, links, and associations. A constraint
restricts the values that entities can assume.

Examples include:
- a constraint between two things at the same time;
Constraints
- a constraint between properties of a single object; on objects
- constraint on the same object over time.

Simple constraints may be placed in object model.

Complex constraints should be specified in the functional model.

boss Window
Employee length Job
salary width priority

{salary ≤ boss.salary} {0.8 ≤ length/width ≤ 1.5} {priority never increases}

 CONSTRAINTS O N LINKS

Multiplicity constraints an {ordered}

association. It restrict the number of Country Office Person
objects related to a given object.

The notation "{ordered}" indicates

that the elements of the "many" end Constraints on
of an association have an explicit association links
order that must be preserved.

GENERAL CONSTRAINTS

Subset Member_of
constraint
Person {subset} Committee
between
associations Chair_of
 DERIVED OBJECTS, LINKS, A N D ATTRIBUTES

✘ A derived object is defined as a

Person
function of one or more objects, which birthdate Current
in turn may be derived. The derived date
/age
object is completely determined by the
other objects. {age = currentdate - birthdate}

✘ Similarly, there are also derived links

and derived attributes. Derived

attribute
✘ The derived value notation is optional.

Machine Assembly Part

Derived
object and offset offset NetOffset
association
{offset = assembly_machine.offset Offset
× part_assembly.offset}

It is important to distinguish independent and dependent entities in a model.

Derived entities are constrained by their base entities and the derivation
rule.
 HOMOMORPHISMS

A homomorphism maps between two associations.

Homomorphism
for a parts
catalog
mapping

Maps
Contains Contains

CatalogItem Item

model number serial number

Describes

{item1 contains item2 ‹ item1.model contains item2.model}

In general, a homomorphism involves four relationships among four classes as
shown on the figure below.

mapping

r
A B

General
t u homomorphism
{u(b,d) ‹ t(b.r, d.s)}

C D
s

Homomorphisms are most likely to occur for complex applications that deal with
metadata. The homomorphism is essentially just an analogy: a special type of
relationship between relationships.