Module 4: Relationships

1
Module 4 Relationships
2
Overview

• Relationships
• Dependency
• Generalization
• Association
• Realization (See Module 2 for this)
• Modeling Techniques

3
Relationships and Associations
different words, but more or less same concept

• UML
• Associations
• Fusion
• Relationships
• OMT
• Associations

4
Relationships 3 Kinds
Event
dependency
generalization
ConsoleWindow
DialogBox
Control
association
5
Dependency

• A change in one thing may affect another.
• Uses relationship.
• May have a name, but not common.

AudioClip
name
Microphone
record(mMicrophone) start() stop()
dependency
One important use of dependency
6
Generalization

• Relationship between general thing (parent) and
  more specific thing (child)
• Child is-a-kind-of parent.
• Child inherits attributes and operations of
  parent.

generalization
Shape
base class
Rectangle
Polygon
Circle
leaf class
Square
7
Associations (UML)

• Represent conceptual relationships between classes

direction indicatorhow to read relation name
relationship name
teaches
1..

teacher
class
role names
Multiplicity defines the number of objects
associated with an instance of the
association. Default of 1 Zero or more ()
n..m range from n to m inclusive
8
Associations - In Other OOAD
Associations may be binary, ternary, or higher
order
binary association
Professor
Course
Fusion Style
Ternary association
Language
Project
Person
How are these represented in UML?
9
Associations A Question

• How would you model the following situation?
• You have two files, say Homework1 and MyPet,
  where Homework1 is accessible only by you, but
  MyPet is accessible by anybody.
• You could create two classes, File and User.
  Homework1 and MyPet are files, and you are a
  user.
• Approach 1 Now, would you associate the file
  access right with File?
• Approach 2 Or, would you associate the file
  access right with User?

10
Associations Links

• UML has links and associations whose ideas
  originate largely from OMT and also from Fusion
  to a certain extent.
• OMT has links
• link is a physical or conceptual connection
  between object instances. E.g., MyPet
  is-accessible-to by any user.
• OMT has association
• describes a group of links with common structure
  and common semantics

• Inherently bi-directional
• Often implemented as pointers in programming
  languages
• In other advanced OOAD notations, such as RML
  (Requirements Modeling Language), relationships
  including associations are treated fully and
  uniformly as classes. And as such they can have
  links as instances.

11
Associations UML Links

• link is a semantic connection among objects.
• A link is an instance of an association.

association
class
class
association name
Company

1..
works for
employee
employer
w Worker
assign(development)
Company
link
Anonymous object
Named object
12
Associations Link Attributes

• Link Attributes
• The most compelling reason for having links
  and attributes is for-many-to-many relationships

File
User
link attribute
access permission

• UML Association Class

1..
File
User

class
class
AccessRight
access permission
association class
13
Associations - Aggregation

• structural association representing whole/part
  relationship.
• has-a relationship.

whole
part
multiplicity
1..
Company
Department
association
aggregation
14
Modeling Techniques

• Simple dependencies
• Single inheritance
• Structural relationships

15
Modeling Simple Dependencies

• The most common dependency between two classes is
  one where one class uses another as a parameter
  to an operation.
• Create dependency pointing from class with
  operation to parameter.

Using relationship
CourseSchedule addCourse(c Course) removeCourse
(c Course
Course
Usually initial class diagrams will not have any
significant number of dependencies in the
beginning of analysis but will as more details
are identified.
16
Modeling Single Inheritance

• Look for common responsibilities, attributes, and
  operations that are common to two (2) or more
  classes.
• If necessary, create a new class to assign
  commonalities.
• Specify that the more-specific classes inherit
  from the more-general.

In UML, abstract classes and their operations
would be italicized. But not in Rational Rose
Security
presentValue() history()
abstract
is-a-kind-of relationship
CashAccount
Stock
Bond
interestRate
presentValue()
presentValue()
presentValue()
PreferredStock
CommonStock
17
Modeling Single Inheritance (contd)

• Abstract
• Abstractionthe essential characteristics of a
  thing.
• Abstract classcannot be instantiated.
• Abstract methodhas no implementation defined
  (i.e., no method body).
• Depicted in italics or with stereotypes.
• Concrete
• Not abstract.
• Can have instances.

18
Modeling Structural Relationships

• Considering a bunch of classes and their
  association relationships

1
0..1
School
Department
has
1..
1..
1..
1..
5
assigned to
5
member

1..
1..
1
chairperson

4
1..
3
attends
teaches
Instructor
Course
Student


The model above is from Rational Rose. How did
the composite symbol ( )get loaded versus the
aggregation? Use the Role Detail and select
aggregation and then the by value radio button.
19
Modeling Structural Relationships
Composite
Aggregation
Body
Car
Liver
Heart
Wheel
Engine
Composite is a stronger form of aggregation.
Composite parts live and die with the whole.
20
Modeling Structural Relationships

• Specify an association to create a navigation
  path between two objects (in either direction).
• Specify an association if two objects interact
  with each other beyond operation arguments.
• Specify multiplicity 1 is assumed. (Error in
  text on implicit default.)
• Specify aggregation when one of the classes
  represents a whole over the other classes.

• How do you know that objects of one class must
  interact with another class?
• Review the scenarios that were derived from Use
  Cases.
• CRC cards seem much less used in practice..

21
Hints Tips

• Modeling relationships
• Use dependencies when relationship is not
  structural.
• Use generalization with is-a relationship.
• Dont introduce cyclical generalizations.
• Balance generalizations - Not too deep, not too
  wide.
• Use associations where structural relationships
  exist.

• Drawing a UML relationship
• Use rectilinear or oblique lines consistently.
• Avoid lines that cross.
• Show only relationships necessary to understand a
  particular grouping of things.
• Elide redundant associations.

22
Summary

• Relationships
• Dependency
• Generalization
• Association
• -Links and Link Attributes
• -Aggregation
• Modeling techniques

• Simple dependencies
• Single inheritance
• Structural relationships

23
Points To Ponder

• Show that cyclical generalizations lead to
  symmetric relationships between two classes. Use
  a couple of examples.
• Why are cyclical generalizations not desirable?
• Show that associations do not lead to transitive
  relationships but aggregations do. Use a couple
  of examples.
• Express compositions using FOL (first-order
  logic).
• Show that two classes C1 and C2 can be such that
  C2 is a subclass of C2 but at the same time C2 is
  an aggregation of C1. Use a couple of examples.
• Show that two association classes can be related
  to each other, for example, through an
  association.
• Can you give a counter-example to the statement
  Composite parts live and die with the whole? Or
  when would the statement not hold?