1. Chapter 18: Refining Analysis Relationships
CS 426
Senior Projects in Computer Science
Chapter 18: Refining Analysis Relationships
[Arlow and Neustadt, 2005]
University of Nevada, Reno
Department of Computer Science & Engineering

2. Outline Design relationships Aggregation and composition
How to refine analysis relationships
One-to-one associations
Many-to-one associations and One-to-many associations
Collections
Reified relationships

3. Design relationships
Refining analysis relationships into design relationships involves:
Refining associations to aggregations or compositions
Implementing one-to-many associations
Implementing many-to-one associations
Implementing many-to-many associations
Implementing bidirectional associations
Implementing association classes

4. Design associations Design associations must have
Navigability
Multiplicity on both ends
Design associations should have
An association name
A role name on at least the target end

5. Aggregation and composition
Aggregation is a “whole-part” relationship
Composition is a stronger type of aggregation (no sharing of parts; parts are destroyed when the assembly is destroyed)

6. Aggregation semantics
The aggregate can sometimes exist independently of parts, sometimes not
The parts can exist independently of the aggregate
The aggregate is incomplete if some parts are missing
It is possible to share parts among several aggregates

7. Aggregation semantics
Aggregation is transitive
Aggregation is asymmetric

8. Aggregation semantics
However, association is symmetric

9. Aggregation semantics
Another example of aggregation

10. Composition semantics
The parts cannot be shared with any other aggregate
The composite has sole responsibility for the disposition of its parts
The composite may release parts, if responsibility for them is given to another composite
If the composite is destroyed, it must destroy all its parts

11. Composition and attributes
A part in a composite is equivalent with an attribute
Why is necessary to use two ways to express the same thing?
Attributes may be primitive data types (e.g., int, double)
Utility classes are better modeled as attributes (e.g., Time, Date, String)

12. Refining analysis relationships
Refining associations into aggregations or compositions:
Add multiplicities and role names to the association
Decide which side is a whole and which is a part
If multiplicity at the whole is 1, then you may be able to use composition, otherwise it must be aggregation
Add navigability from the whole to the part (design associations must be unidirectional)

13. One-to-one associations
1-to-1 associations almost always are compositions

14. One-to-one associations
1-to-1 associations can also be modeled using attributes

15. Many-to-one associations
If there are no cycles in the aggregation graph, aggregations can be used

16. One-to-many associations
There is a collection of objects on the part side of the relationship
Use either native support for collection, or use collection classes (more flexible and powerful)

17. Collection classes
A collection class is a class whose instances specialize in managing collections of other objects
They 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

18. Collection classes
Example of using collections:

19. Collection classes - strategies
Four strategies for software modeling with collections:
Model the class explicitly (see previous slide)
Use tagged values to inform the modeling tool about implementation
Use properties to specify semantics, but don’t specify implementation
Do not refine one-to-many relationships to collections (leave it up to the programmers)

20. Collection classes
Standard UML properties for collections:

21. Collection classes
UML types of collections:

22. Collection classes: the maps
Maps are optimized to quickly return a value, given a key
Use notation {map, key}

23. Reified relationships
Some types of relationships are pure analysis artifacts and need to be reified (reification = to make concrete, or real)
The following analysis relationships need to be reified:
Many-to-many associations
Bidirectional associations
Association classes

24. Reified relationships: Many-to-Many
Decide which side is the whole and use aggregation or composition as appropriate
Example: allocation association reified into Allocation class

25. Reified relationships: Bidirectional
Bidirectional relationships are fine in analysis
However, in design they must be reified due to lack of implementation support

26. Reified relationships: Association classes
Association classes are purely analysis artifacts