The purpose of this workflow detail is to refine the design of the system.

Topics


      Analysis Class
Analysis
Class
  Analysis Class
Analysis
Class
  Design Class
Design Class
  Interface
Interface
Design Subsystem
Design Subsystem
  Use Case
Use Case
 
               
 
Designer
Designer
 

 
Enterprise JavaBean (EJB) Design
Enterprise
JavaBean
(EJB) Design

 
Class Design
Class Design

 
Design Testability Elements
Design Testability
Elements

 
Subsystem Design
Subsystem
Design

 
Use-Case Design
Use-Case
Design

 
               
      Design Model
Design Model
Enterprise Java Bean (EJB)
Enterprise
Java Bean
(EJB)
  Design Model
Design Model
Design Class
Design Class
  Design Package
Design Package
Testability Class
Testability
Class
  Design Subsystem
Design Subsystem
Design Class
Design Class
  Design Model
Design Model
Design Use-Case Realization
Design Use-Case
Realization
 
                  Interface
Interface
Design Model
Design Model
     

      Navigation Map
Navigation
Map
Design Model
Design Model
 
       
 
Technical Reviewer
Technical
Reviewer

 

 
Review the Design
Review the
Design

 
       
      Review Record
Review Record
 


Description To top of page

This Workflow Detail has the following goals:

  • Refine the definitions of design elements by working out the 'details' of how the design elements realize the behavior required of them.
  • Refine and update the use-case realizations based on new design element identified (i.e. keeping the use-case realizations updated)
  • Reviewing the design as it evolves

Related Information To top of page

This section provides links to additional information related to this workflow detail.

Timing To top of page

Starts in Elaboration phase. Recurs through Construction and Transition phases.

Optionality To top of page

Required

How to Staff To top of page

Typically, one person or a small team is responsible for a set of design elements, usually one or more packages or subsystems containing other design elements. This person/team is responsible for fleshing out the design details for the elements contained in the package or subsystem: completing all operation definitions and the definition of relationships to other design elements. The Activity: Class Design focuses on refining the design of class design elements, while the Activity: Subsystem Design focuses on the allocation of behavior mapped to the subsystem itself to contained design elements (either contained classes or subsystems).

Individuals responsible for designing classes should also be knowledgeable in the implementation language as well as in algorithms or technologies to be employed by the class. Individuals or teams responsible for subsystems should be more generalists, able to make decisions on the proper partitioning of functionality between design elements, and able to understand the inherent trade-offs involved in various design alternatives.

While the individual design elements are refined, the use-case realizations must be refined to reflect the evolving responsibilities of the design elements. Typically, one person or a small team is responsible for refining one or more related use-case realizations. As design elements are added or refined, the use-case realizations need to be reconsidered and evolved as they become outdated, or as improvements in the design model allow for simplifications in the use-case realizations. The individuals or teams responsible for use-case realizations need to have broader understanding of the behavior required by the use cases and of the trade-offs of different approaches to allocating this behavior amongst design elements. In addition, since they are responsible for selecting the elements that will perform the use cases, they need to have a deep understanding of external (public) behaviors of the design elements themselves.

Work Guidelines To top of page

Typically the work here is carried in individually or in small teams, with informal inter-group interactions where needed to communicate changes between the teams. As design elements are refined, responsibilities often shift between them, requiring simultaneous changes to a number of design elements and use-case realizations. Because of the interplay of responsibilities, it is almost impossible for design team members to work in complete isolation. To keep the design effort focused on the required behavior of the system (as expressed in use-case realizations), a typical pattern of interaction emerges:

  • design elements are refined by the responsible persons or teams
  • a small group (perhaps 2-5 people) gathers informally to work out the impact of the new design elements on a set of existing use-case realizations
  • in the course of the discussion, changes to both the use-case realization and the participating design elements are identified
  • the cycle repeats until all required behaviour for the iteration is designed.

Because the process itself is iterative, the criteria for 'all required behaviour for the iteration' will vary depending on the position in the lifecycle:

  • In the elaboration phase, the focus will be on architecturally-significant behaviors, with all other 'details' effectively ignored (or more likely 'stubbed-out')
  • In the construction phase there is a shift to completeness and consistency of the design, so that by the end of the construction phase there are no unresolved design issues.

Note that the design for an iteration does not need to be complete before beginning implementation and test activities. Partially implementing and testing a design as it evolves can be an effective means of validating and refining design, even within an iteration.


Rational Unified Process   2003.06.15