3.2.5. Associations: The Relations Is - A and Has - A Are Fundamental Ways To Understand Collections of Classes

3.2.5.
Associations
The relations is_a and has_a are fundamental
ways to understand collections of classes.
In an OO implementation these relations

will usually be visible in the code.
But they are not the only interesting relations!

Almost every OO model features relations
which are ad hoc and reflect the special
semantical meaning or intension of classes.
Such general relations are called associations.
They are used in database theory, where

• records, and
• relationships between records
are described in Entity/Relationship diagrams.
Reasons:
• because two or more objects may exchange

messages or services,
• because two or more objects may co-exist
independently, or dependently
• because a relation may clarify the meaning
of a class when we don’t quite know what it
is yet.
• etc. etc. …
So aspects of dynamical behaviour and
meaning may be visible in a (static) class
diagram.
An important association will be reflected in

the code somewhere, but not in any naïve
way,
e.g. inheritance construct, line 27, etc.

The simplest association is binary and
represented by a line … e.g.
<name>
Class_A Class_B
Normally, we at least annotate the association

with a <name>, e.g.
studies
Student Course
name title
An arrow can be added to show the orientation

or asymmetry of the relation.
In this case studies is not symmetric.

Actually, this asymmetry is already implicit
in the two different class names.
We can also make the asymmetry explicit

and more interesting by assigning
role names
For example …
subject
Student Course
participant
name title
The existence of an association between two

classes often indicates some level of coupling,
in the sense of related concepts.
According to standard practice, coupling should

be minimized and cohesion maximized.
Excessive coupling often indicates a bad
architectural decomposition.
Many associations (relations) are binary,

but not all! Some are:
• ternary relations (3 arguments)

• n-ary relations (n arguments)
E.g. a ternary relation can be drawn as:
Men Women
marries
Priests
and we can add more classes to the diamond.

3.2.6. Multiplicity of
Associations
In an ER diagram it is common to give the
multiplicity of each component of a relation.
In OO analysis and design this can help to

implement, test and debug the code.
The commonest multiplicities are:
• One-to-one
tax_coding
John Smith
760901-1234
Mary Jones
691205-5678
People Tax_codes
• One-to-many
mother_of
M.E. Meinke
K. Meinke
N. Meinke
Women
People
• Many-to-many
parent_of
M.E. Meinke
K. Meinke
K.W. Meinke
N. Meinke
People People
Relation R between classes X and Y is:
n-to-… if for every object y :Y there are

n distinct objects x1 ,…, xn : X with
xi R y for i = 1 ,…, n
…-to-m if for every object x :X there are

m distinct objects y1 ,…, ym : Y with
x R yi for i = 1 ,…, m
So e.g. parent_of is 2-to-many.
UML has a notation for multiplicity:
• 1 one and only one

• 0 .. 1 zero or one
• M .. N from M to N
• * greater than or equal to zero
• 0 .. * …same …
• M .. * greater than or equal to M
Examples: one-to-one
1 1
Class_A Class_B
one-to-many
1 *
Class_A Class_B
many-to-many
* *
Class_A Class_B
We can also add multiplicity constraints

to aggregation and composition relations,
e.g. …
1 Class_A object has many Class_B objects
1 *
Class_A Class_B
We can express a choice of multiplicities
in other ways, e.g
• 1, 3, 5 1 or 3 or 5
• 7, 9 .. 12 7 or 9 or 10 or 11 or 12
3.3. Mapping to Code
MyPackage package MyPackage
abstract class
MyAbstractClass
MyAbstractClass
package MyPackage
class MyDerivedClass
extends MyAbstractClass
MyDerivedClass {
att: int int att;
void myFunction(
myFunction() referencedClass r ) { .. }
}
Aggregation
MyClass class MyClass

{
att: int
MyAggregatedClass ac;
myFunction()
int att;
ac void myFunction(
referencedClass r ) { .. }
MyAggregatedClass }
Dependence
3 possible implementations!
class MyDependentClass
MyClass {
void myFunction1(
att: int
MyReferencedClass r ) { .. }
myFunction()
MyreferencedClass
dependence myFunction2( .. ) { .. }
arrow
MyReferencedClass void myFunction3( .. )

{ MyReferencedClass m .. }
}
3.3. Object Diagrams
Introduction.
An object diagram represents a specific
collection of objects, with specific attribute
values and relationships.
Therefore it looks like a snapshot of an O-O

system at some instant in time.
We can draw an object diagram to try to
instantiate a particular class diagram.
An object diagram O is a valid instance a

class diagram C if, and only if, O satisfies
all the constraints (numerical and logical)
of C.
This means we must check (validate) whether

O really instantiates C.
In fact, even without any class diagrams,
we can just draw object diagrams to help us
think about how the system might look.
So object diagrams are a complement or

an alternative to class diagrams.
An object diagram is also called an

instance diagram.
Common uses of object diagrams are:
1. to illustrate the system state at a high

level of abstraction, before and after
some action (e.g. instruction execution)
i.e. dynamic modeling !!
2. to analyze the structure of recursive

data types (classes) by unfolding a
class diagram.
3.3.1. Objects
An object is drawn as a rectangle, containing
possibly the:
• object name,
• object type (class),
• attribute names,
• attribute values.
For example …
typeless
name name :
type
: type name :
type
attribute = value
anonymous
3.3.2. Links
A link is a concrete instance of an association
or relation.
A class can be modeled as the set of all its

instances. Then an n-ary association (relation)
R is modeled as an n-ary relation on these
sets.
In this case, a link is a specific n-tuple of
objects:
l = ( o1 , …, on )  R
Graphically a link looks like an association,

only the context distinguishes the two.
Association and role names are copied over to

links.
However:
1. Logical constraints on associations are

carried over as the presence or absence of
links.
2. Numerical constraints on associations

are carried over as numbers of links
between endpoints.
For example, the following object diagram (below)
is a legal instance of the class diagram (above):
has
Biplane Wing
2
Upper_wing :
has Wing
Sopwith-Camel :
Biplane
has
Lower_wing :
Wing
But this object diagram is not a valid instance
of the previous class diagram:
Sopwith-Camel : has Lower_wing :

Biplane Wing
since it has the wrong number of links

(1 instead of 2 on RHS)
Ternary and n-ary relations are represented
using the diamond as before, e.g.
Object_1 : Object_2 :
Class_1 Class_2
Object_3 :
Class_3
Object composition and aggregation use the
same symbols as for classes, e.g.
Component1 : Component2 :
Class_1 Class_2
Object :
Class
Notice that now we can capture the semantic
difference between composition and
aggregation. E.g. the following is illegal
P1 : Polygon L1 : Line
!!!!!
Start : Point Myname : Name
x=0 text = “big”
y=0
We can use object diagrams to understand
recursively defined classes. For example,
the class diagram
Binary_Tree
0,1
0 .. 2
has the object diagram
T1 : Binary
Tree
T2 : Binary T3 : Binary
Tree Tree
T4 : Binary T5 : Binary
Tree Tree
4. Software Architectures
Software architecture: structure or structures
of the system which comprise software
components, externally visible properties of
these components, and relationships among
them.
Not the operational software!

Purposes: enables software engineer to …
1. Analyse effectiveness of design in
meeting requirements ..
2. Because small intellectually graspable
model of how components collaborate
3. So, consider architectural alternatives at a
stage when making changes is still easy
4. Hence, reduces project risks associate
with software construction.
Lets see a classification of architectures,
taken from
M. Shaw & D. Garlan, Software Architecture,

Prentice Hall, 1996.
Note: our list is just a sample!

4.1 Data Flow
Data flows between static functional
elements which transform it, aka pipeline
architecture e.g. compiler
C code parse assembler Machine
tree code
Parse Translate Link &

procedure Assemble
assembler
calls
Library
4.2. Model-View-Controller
MVC
• An architectural model that solves many user
interface (UI) problems, e.g.
• shared data,
• multiple users,
• different views of the same data,
• updating information across all users,
• changes to underlying data,
• changes to representation
Architecture Goals
• Same information capable of being
presented in different formats in different
windows
• Changes made in one view should be
immediately reflected in other views
• Changes in the UI should be easy to make
• Core functionality should be independent of
the interface to enable multiple interface
styles

3.2.5. Associations: The Relations Is - A and Has - A Are Fundamental Ways To Understand Collections of Classes

Uploaded by

Copyright:

Available Formats

3.2.5. Associations: The Relations Is - A and Has - A Are Fundamental Ways To Understand Collections of Classes

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3.2.5. Associations: The Relations Is - A and Has - A Are Fundamental Ways To Understand Collections of Classes

Uploaded by

Copyright:

Available Formats

3.2.5.

In an OO implementation these relations

But they are not the only interesting relations!

Such general relations are called associations.

They are used in database theory, where

• because two or more objects may exchange

An important association will be reflected in

e.g. inheritance construct, line 27, etc.

Normally, we at least annotate the association

An arrow can be added to show the orientation

In this case studies is not symmetric.

We can also make the asymmetry explicit

The existence of an association between two

According to standard practice, coupling should

Many associations (relations) are binary,

• ternary relations (3 arguments)

and we can add more classes to the diamond.

In OO analysis and design this can help to

n-to-… if for every object y :Y there are

…-to-m if for every object x :X there are

UML has a notation for multiplicity:

• 1 one and only one

We can also add multiplicity constraints

MyClass class MyClass

MyReferencedClass void myFunction3( .. )

Therefore it looks like a snapshot of an O-O

An object diagram O is a valid instance a

This means we must check (validate) whether

So object diagrams are a complement or

An object diagram is also called an

1. to illustrate the system state at a high

2. to analyze the structure of recursive

A class can be modeled as the set of all its

Graphically a link looks like an association,

Association and role names are copied over to

1. Logical constraints on associations are

2. Numerical constraints on associations

Sopwith-Camel : has Lower_wing :

since it has the wrong number of links

Not the operational software!

M. Shaw & D. Garlan, Software Architecture,

Note: our list is just a sample!

Parse Translate Link &

You might also like