5
Rational
Proprietary and
Confidential
Supplementary
Specifications
Software Architecture
Document
Design Model
Design Model
Design
Guidelines
Analysis Classes
Identify Design Elements Overview
Identify Design
Elements
6
Rational
Proprietary and
Confidential
Purpose
Purpos e
Purpos e
:
:
To analyze interactions of analysis classes to find
interfaces, classes and subsystems.
To refine the architecture, incorporating reuse
where possible.
To identify common solutions to commonly
encountered design problems.
To include architecturally significant parts of the
design model in the Logical View
7
Rational
Proprietary and
Confidential
Input and Output
Input Artifacts
Input Artifacts
:
:
Supplementary Specifications
Glossary
Software Architecture Document
Design Model
Analysis Classes
Design Guidelines
Res ulting Artifacts
Res ulting Artifacts
:
:
Design Model (Classes and Subsystems)
Updated Software Architecture Document
Updated Design Guidelines
8
Rational
Proprietary and
Confidential
Class, Subsystem, interface overview
Classes, to represent a set of rather fine-grained
Classes, to represent a set of rather fine-grained
responsibilities;
responsibilities;
Subsystems, to represent a set of coarse-grained
Subsystems, to represent a set of coarse-grained
responsibilities, eventually composed of a further set of
responsibilities, eventually composed of a further set of
classes and possibly subsystems;
classes and possibly subsystems;
Interfaces, to represent abstract declarations of
Interfaces, to represent abstract declarations of
responsibilities provided by a class or subsystem;
responsibilities provided by a class or subsystem;
9
Rational
Proprietary and
Confidential
Identify Design Elements Steps
Identify classes and subsystems
Identify classes and subsystems
Identify subsystem interacts
Identify subsystem interacts
Update the organization of the design model
Update the organization of the design model
Checkpoints
Checkpoints
10
Rational
Proprietary and
Confidential
Identify Design Elements Steps
Identify classes and subsystems
Identify classes and subsystems
Identify subsystem interfaces
Identify subsystem interfaces
Identify reuse opportunities
Identify reuse opportunities
Update the organization of the design model
Update the organization of the design model
Checkpoints
Checkpoints
11
Rational
Proprietary and
Confidential
Analysis Classes Design Elements
Many-to-Many Mapping
From Analysis Classes to Design Elements
<<boundary>>
<<control>>
<<entity>>
<<boundary>>
12
Rational
Proprietary and
Confidential
From Analysis Classes to Design Elements (cont.)
Analysis classes handle primarily functional
Analysis classes handle primarily functional
requirements, and model objects from the
requirements, and model objects from the
"problem" domain; design elements handle non-
"problem" domain; design elements handle non-
functional requirements, and model objects from
functional requirements, and model objects from
the "solution" domain.
the "solution" domain.
We decide what analysis ‘classes’ are really
We decide what analysis ‘classes’ are really
classes, which are subsystems (which must be
classes, which are subsystems (which must be
further decomposed), and which are existing
further decomposed), and which are existing
components and don’t need to be “designed” at
components and don’t need to be “designed” at
all.
all.
13
Rational
Proprietary and
Confidential
From Analysis Classes to Design Elements (cont.)
Once the design classes and subsystems have
Once the design classes and subsystems have
been created, each must be given a name and a
been created, each must be given a name and a
short description. The responsibilities of the
short description. The responsibilities of the
original analysis classes should be transferred to
original analysis classes should be transferred to
the newly-created subsystems
the newly-created subsystems
14
Rational
Proprietary and
Confidential
Identify Design Classes
An analysis class maps directly to a design class if:
An analysis class maps directly to a design class if:
It is a simple class
It represents a single logical abstraction
More complex analysis classes may
More complex analysis classes may
Split into multiple classes
Become a package
Become a subsystem (discussed later)
Any combination…
Không có nhận xét nào:
Đăng nhận xét