View
3
Download
0
Category
Preview:
Citation preview
1Sharif University of TechnologyDepartment of Computer Engineering
Object-Oriented Design
Lecturer: Raman Ramsin
Lecture 16:
Refining Analysis Relationships
2
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Refining Analysis Relationships
Relationships in analysis are converted to implementable design relationships.
Refining analysis relationships to design relationships involves:
adding navigability;
adding multiplicity to both ends of the association;
adding a role name at both ends of the association, or at least on the target end of the association;
refining relevant associations into aggregation or compositionwhere appropriate;
implementing one-to-one, one-to-many, many-to-one, and many-to-many associations;
implementing bidirectional associations and association classes;
using structured classifiers for modeling composition.
3
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Aggregation Relationship
Whole-part relationship where objects of one class act as the whole or aggregate, and objects of the other class act as the parts:
the whole uses the services of the parts; the parts service the requests of the whole;
the whole is the dominant, controlling side of the relationship; the part tends to be more passive.
4
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Aggregation Relationship: Transitivity
If C is part of B and B is part of A, then C is part of A.
5
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Aggregation Relationship: Asymmetry
Aggregation relationship is asymmetric:
a whole can never directly or indirectly be a part of itself;
there must never be a cycle in the aggregation graph.
6
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Aggregation and Composition
There are two types of aggregation relationship:
Aggregation;
Composition Aggregation - usually referred to simply as Composition.
7
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Aggregation: Semantics
The aggregate can sometimes exist independently of the parts, sometimes not;
The parts can exist independently of the aggregate;
The aggregate is in some way incomplete if some of the parts aremissing;
It is possible to have shared ownership of the parts by several aggregates;
Aggregation hierarchies and aggregation networks are possible;
The whole always knows about the parts, but if the relationship is one-way from the whole to the part, the parts don't know about the whole.
8
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Aggregation: Example
Aggregation is like a computer and its peripherals:
a computer is only weakly related to its peripherals;
peripherals may come and go;
peripherals may be shared between computers;
peripherals are not in any meaningful sense "owned" by any particular computer.
9
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Aggregation: Example
10
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
CompositionA strong form of aggregation:
the parts belong to exactly one composite at a time;
the composite has sole responsibility for the disposition of all its parts - this means responsibility for their creation and destruction;
the composite may also release parts, provided responsibility for them is assumed by another object;
if the composite is destroyed, it must destroy all its parts or give responsibility for them over to some other object;
each part belongs to exactly one composite so you can only have composition hierarchies - composition networks are impossible.
11
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Composition: Example
Composition is like a tree and its leaves:
leaves are owned by exactly one tree;
leaves can't be shared between trees;
when the tree dies, its leaves go with it.
12
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Composition and Attributes
A part in a composite is equivalent to an attribute:
use explicit composition when the parts are important and interesting;
use attributes when the parts are neither important nor interesting.
13
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Refining Analysis Relationships: Aggregation
Analysis associations should be refined into one of the aggregation relationships wherever possible.
If this would create a cycle in the aggregation graph, then it is impossible, and you must use an association or a dependency.
Procedure for refining associations to aggregation relationships:
add multiplicities and role names;
decide which side of the relationship is the whole and which is the part;
look at the multiplicity of the whole side:
if it is 1, you may be able to use composition - check that the association has composition semantics, then apply composition;
if it is not 1, use aggregation;
add navigability from the whole to the part .
14
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Refining Analysis Relationships: One-to-One Association
This almost always becomes composition. However, you may also choose to use an attribute instead or to merge the two classes.
15
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Refining Analysis Relationships: Many-to-One Association
Use aggregation - as there are many on the whole side, you can't use composition;
Check for cycles in the aggregation graph.
16
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Refining Analysis Relationships: One-to-Many Association
There is a collection of objects on the part side:
Use an inbuilt array (most OO languages directly support arrays) - they are generally quite inflexible but are usually fast;
Use a collection class - they are more flexible than inbuilt arrays and are faster than arrays when searching the collection is required (otherwise they are slower).
17
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Collections
Classes specialized so that their instances can manage a collection of other objects.
All collection classes have operations for:
adding objects to the collection;
removing objects from the collection;
retrieving a reference to an object in the collection;
traversing the collection - stepping through the collection from the first object to the last.
18
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Modeling with Collections
There are four options:
1. model the collection class explicitly;
19
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Modeling with Collections
There are four options:
1. model the collection class explicitly;
2. tell the modeling tool which collection to use by adding a property to the relationship;
20
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Modeling with Collections
There are four options:
1. model the collection class explicitly;
2. tell the modeling tool which collection to use by adding a property to the relationship;
3. tell the programmer what collection semantics are required by adding a property to the relationship;
21
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Modeling with Collections
There are four options:
1. model the collection class explicitly;
2. tell the modeling tool which collection to use by adding a property to the relationship;
3. tell the programmer what collection semantics are required by adding a property to the relationship;
22
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Modeling with Collections
There are four options:
1. model the collection class explicitly;
2. tell the modeling tool which collection to use by adding a property to the relationship;
3. tell the programmer what collection semantics are required by adding a property to the relationship;
23
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Modeling with Collections
There are four options:
1. model the collection class explicitly;
2. tell the modeling tool which collection to use by adding a property to the relationship;
3. tell the programmer what collection semantics are required by adding a property to the relationship;
4. instead of refining one-to-many relationships to collection classes, leave it up to the programmers.
Don't "overmodel" - the choice of a specific collection class is often a tactical issue that can be left to the programmer at implementation time.
24
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Also known as the dictionary;
Given a key, the corresponding value may be found very quickly;
Acts like a database table with two columns, the key and the value;
Keys must be unique.
Modeling with Collections: The Map
25
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Reifying Analysis Relationships
Some relationships are pure analysis artifacts and must be made implementable by the process of reification:
1. Many-to-many associations
2. Bidirectional associations
3. Association classes
26
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Reifying Relationships: Many-to-Many Associations
1. Reify the relationship into a class.
2. Decide which side is the whole and use aggregation, composition, or association as appropriate.
27
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Reifying Relationships: Bidirectional Associations
Replace with a unidirectional aggregation or composition from whole to part, and a unidirectional association or dependency from part to whole.
28
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Reifying Relationships: Association Classes
1. Decide which side is the whole and which is the part;
2. Replace with a class (usually with the same name as the association class);
3. Add a constraint in a note to indicate that objects on each end of the reified relationship must form a unique pair.
29
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Structured Classifier
A classifier (such as a class) that has an internal structure.
Modeled as parts that are joined with connectors:
part - a role that one or more instances of a classifier can play in the context of the structured classifier;
name - the name of the part;
type - the type of objects that can play the role;
multiplicity - the number of objects that can play the role at any time;
connector - a relationship between parts in the context of a structured classifier.
30
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Structured Classifier: Notation
31
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Structured Class
A class that has an internal structure;
Has the extra constraint that it owns (has an implicit containment relationship with) all of its parts, connectors, and ports.
32
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Structured Class: Modeling
Internal structure can be shown on class diagrams or on a composite structure diagram.
33
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Structured Class: Modeling – Composite Structure Diagrams
34
Object-Oriented Design – Lecture 16
Sharif University of TechnologyDepartment of Computer Engineering
Reference
Arlow, J., Neustadt, I., UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design, 2nd Ed. Addison-Wesley, 2005.
Recommended