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

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

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

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

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)

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

Aggregation semantics Aggregation is transitive Aggregation is asymmetric

Aggregation semantics However, association is symmetric

Aggregation semantics Another example of aggregation

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

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)

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)

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

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

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

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)

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

Collection classes Example of using collections:

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)

Collection classes Standard UML properties for collections:

Collection classes UML types of collections:

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

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

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

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

Reified relationships: Association classes Association classes are purely analysis artifacts