Module04_UML_Ch5_Relationships123456.ppt

Realtionships

1. OOP 1
Module 4: Relationships

2. OOP 2
Overview
Relationships
Dependency
Generalization
Association
Realization (See Module 2 for this)
Modeling Techniques

3. OOP 3
Relationships and Associations
UML
Associations
Fusion
Relationships
OMT
Associations
different words, but more or less same concept

4. OOP 4
Relationships: 3 Kinds
Window
open()
close()
ConsoleWindow DialogBox Control
Event
association
dependency
generalization

5. OOP 5
AudioClip
Dependency
A change in one thing may affect another.
“Uses” relationship.
May have a name, but not common.
record(m:Microphone)
start()
stop()
Microphone
name
dependency
One important use of dependency

6. OOP 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.
Rectangle
Square
PolygonCircle
Shape base class
leaf class
generalization

7. OOP 7
Associations (UML)
Professor Course
teaches
relationship name
direction indicator:
how to read relation name
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
1..*
*
Represent conceptual relationships between classes

8. OOP 8
Associations - In Other OOAD
Professor Course
teaches
Fusion Style
binary association
Ternary association
Project
Language
Person
Associations may be binary, ternary, or higher order
How are these represented in UML?

9. OOP 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. OOP 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. OOP 11
Associations – UML Links
link is a semantic connection among objects.
A link is an instance of an association.


Company
1..* *
employee
employer
: Company
assign(development)
w : Worker
link
Named object Anonymous object
class
association
class
Worker
+setSalary( s : Salary)
+setDept( d : Dept)
works for
association name

12. OOP 12
Associations – Link Attributes
Link Attributes
The most compelling reason for having links and attributes is for-many-to-many relationships
File User
access permission
File User
access permission
UML Association Class
AccessRight
* 1..*
link attribute
association class
class
class

13. OOP 13
Associations - Aggregation
CompanyDepartment
1..*
association
multiplicity
aggregation
part
whole
- structural association representing “whole/part” relationship.
- “has-a” relationship.

14. OOP 14
Modeling Techniques
Simple dependencies
Single inheritance
Structural relationships

15. OOP 15
Modeling Simple Dependencies
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.
Using relationship
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.

16. OOP 16
Modeling Single Inheritance
In UML, abstract classes and their
operations would be italicized.
But not in Rational Rose
CashAccount
presentValue()
interestRate
Security
presentValue()
history()
Bond
presentValue()
Stock
presentValue()
PreferredStock CommonStock
abstract
is-a-kind-of relationship
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.

17. OOP 17
Modeling Single Inheritance (cont’d)
Abstract
Abstraction—the essential characteristics of a thing.
Abstract class—cannot be instantiated.
Abstract method—has no implementation defined (i.e., no
method body).
Depicted in italics or with stereotypes.
Concrete
Not abstract.
Can have instances.

18. OOP 18
Modeling Structural Relationships
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.
School
InstructorCourse
Department
Student
*
1..*
1..*
1
has
 member
*
*attends 
*
1..* teaches
1..*
1..* 1..*
1..*
0..1
1chairperson

assigned to
 Considering a bunch of classes and their association relationships

19. OOP 19
Modeling Structural Relationships
Composite is a stronger form of aggregation. Composite parts live and die with the whole.
Liver
Body
Heart
Wheel
Car
Engine
Composite
Aggregation

20. OOP 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. OOP 21
Hints & Tips
Modeling relationships
Use dependencies when relationship is not structural.
Use generalization with “is-a” relationship.
Don’t 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. OOP 22
Summary
Relationships
Dependency
Generalization
Association
-Links and Link Attributes
-Aggregation
Modeling techniques
Simple dependencies
Single inheritance
Structural relationships

23. OOP 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?