Module 7: Identify Design Elements

Identify Classes and Subsystems

- The purpose of Identify Classes and Subsystems is to refine the analysis classes into appropriate Design Model elements.

Identify Design Elements

- Identify Design Elements is where the analysis classes identified during Use-Case Analysis are refined into design elements (for example, classes or subsystems). Analysis classes handle primarily functional requirements, and model objects from the "problem" domain; design elements handle nonfunctional requirements, and model objects from the "solution" domain.

Class - Definition

- A description of a set of objects that share the same responsibilities, relationships, operations, attributes, and semantics

Package - Definition

- A general purpose mechanism for organizing elements into groups

- A model element which can contain other model elements

Classes are functionally related When:

- Changes in one class' behavior and/or structure necessitate changes in another class

- Removal of one class impacts the other class

- Two objects interact with a large number of messages or have a complex intercommunication

- A boundary class can be functionally related to a particular entity class if the function of the boundary class is to present the entity class

- Two classes interact with, or are affected by changes in the same actor

- Two classes have relationships between each other

- One class creates instances of another class

Classes should NOT be placed in the same package:

- Two classes that are related to different actors should not be placed in the same package

- An optional and a mandatory class should not be placed in the same package

Subsystem - Definition

- A subsystem is a model element that has the semantics of a package, such that it can contain other model elements, and a class, such that it has behavior. A subsystem realizes one or more interfaces, which define the behavior it can perform.

- A subsystem can be represented as a UML package (that is, a tabbed folder) with the «subsystem» stereotype.

Interface - Definition

- An interface is a model element that defines a set of behaviors (a set of operations) offered by a classifier model element (specifically, a class, subsystem, or component). The relationship between interfaces and classifiers (subsystems) is not always one-to-one. An interface can be realized by multiple classifiers, and a classifier can realize multiple interfaces.

- Interfaces are a natural evolution from the public classes of a package (described on the previous slide) to abstractions outside the subsystem.  Interfaces are pulled out of the subsystem like a kind of antenna, through which the subsystem can receive signals. All classes inside the subsystem are then private and not accessible from the outside.

Realization - Definition

- Realization is a semantic relationship between two classifiers. One classifier serves as the contract that the other classifier agrees to carry out.

- The realization relationship can be modeled as a dashed line with a hollow arrowhead pointing at the contract classifier (canonical form), or when combined with an interface, as a “ball” (elided form).  Thus, in the above example, the two interface/subsystem pairs with the relation between them are synonymous.

VS Packages and Subsystems

- Subsystems

+ Provide behavior

+ Completely encapsulate their contents

+ Are easily replaced

- Packages

+ Don’t provide behavior

+ Don’t completely encapsulate their contents

+ May not be easily replaced

Subsysem – Identifying Steps

Steps:

- Identify a set of candidate interfaces for all subsystems.

- Look for similarities between interfaces.

- Define interface dependencies.

- Map the interfaces to subsystems.

- Define the behavior specified by the interfaces.

- Package the interfaces.

Reuse Opportunities – Purpose and steps

- Purpose

+ To identify where existing subsystems and/or components can be reused based on their interfaces.

- Steps

+ Look for similar interfaces

+ Modify new interfaces to improve the fit

+ Replace candidate interfaces with existing interfaces

+ Map the candidate subsystem to existing components