Identify Design Elements

Last updated: Jun. 09, 2006

Objectives:

• Define the purpose of Identify Design Elements and demonstrate where in the lifecycle it is performed

• Analyze interactions of analysis classes and identify Design Model elements

  • Design classes

  • Subsystems

  • Subsystem interfaces

Identify Design Elements in Context:

• In Identify Design Elements, the analysis classes are refined into design elements (design classes and subsystems).

• In Use-Case Analysis, you were concerned with the "what." In the architecture activities, you are concerned with the "how" (for example, Design). Architecture is about making choices.

• In this module, we will describe WHAT is performed in Identify Design Elements, but will not describe How to do it. Such a discussion is the purpose of an architecture course, which this course is not.

Identify Design Elements Overview:

• The architect performs Identify Design Elements, once per iteration.

• Purpose: To analyze interactions of analysis classes to identify Design Model elements

• Design Model elements:

  • Classes

  • Packages

  • Subsystems

Identify Design Elements Steps:

• Identify classes and subsystems

• Identify subsystem interfaces

• Update the organization of the Design Model

• Checkpoints

Identify Classes and subsystems:

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

• Analysis classes may be expanded, collapsed, combined, or even deleted in Design.

• 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.

• It is in Identify Design Elements that you decide which analysis "classes" are really classes, which are subsystems (which must be further decomposed), and which are existing components and do not need to be "designed" at all.

• Once the design classes and subsystems have been created, each must be given a name and a short description. The responsibilities of the original analysis classes should be transferred to the newly created subsystems. In addition, the identified design mechanisms should be linked to design elements.

Identifying Design Classes:

• An analysis class maps directly to a design class if:

  • It is a simple class

  • It represents a single logical abstraction

  • Typically, entity classes survive relatively intact into Design.

• More complex analysis classes may:

  • Split into multiple classes

  • Become a package

  • Become a subsystem (discussed later)

  • Any combination...

• In general, there is a many-to-many mapping between analysis classes and design elements. The possible mappings include the following.

  • An analysis class can become:

    • One single class in the Design Model.

    • A part of a class in the Design Model.

    • An aggregate class in the Design Model (meaning that the parts in this aggregate may not be explicitly modeled in the Analysis Model.)

    • A group of classes that inherits from the same class in the Design Model.

    • A group of functionally related classes in the Design Model (for example, a package).

    • A subsystem in the Design Model.

    • A relationship in the Design Model.

  • A relationship between analysis classes can become a class in the Design Model.

  • Part of an analysis class can be realized by hardware, and not modeled in the Design Model at all.

  • Any combination of the above.

Group Design  Classes in Packages:

• The Design Model can be structured into smaller units to make it easier to understand.

• You might want to partition the Design Model for a number for reasons:

  • You can use packages and subsystems as order, configuration, or delivery units when a system is finished.

  • Allocation of resources and the competence of different development teams might require that the project be divided among different groups at different sites.

  • Subsystems can be used to structure the Design Model in a way that reflects the user types. Many change requirements originate from users; subsystems ensure that changes from a particular user type will affect only the parts of the system that correspond to that user type.

  • Subsystems are used to represent the existing products and services that the system uses.