Tài liệu Lesson 5- Identify Design Elements ppt

1
Rational
Proprietary and
Confidential
Object Oriented Analysis and Design
Using the UML
Module 5: Identify Design Elements
Module 5: Identify Design Elements
2
Rational
Proprietary and
Confidential
Objectives: Identify Design Elements

Understand the purpose of the Identify Design Elements
Understand the purpose of the Identify Design Elements
and understand where in the lifecycle it is performed
and understand where in the lifecycle it is performed

To understand how to analyze interactions of analysis
To understand how to analyze interactions of analysis
classes to identify design model elements
classes to identify design model elements

Design classes

Subsystems

Subsystems Interfaces
3
Rational

Proprietary and
Confidential
Identify Design Mechanisms in Context
Architec t
Identify
Des ign
Ele me nts
4
Rational
Proprietary and
Confidential
Identify Design Elements Overview

The
The
Activity: Use Case Analysis
Activity: Use Case Analysis
results in
results in
analysis classes
analysis classes
,
,
which represent
which represent
conceptual things which can perform
conceptual things which can perform
behavior
behavior
. In design,

. In design,
analysis classes
analysis classes
evolve into a number
evolve into a number
of different kinds of design elements:
of different kinds of design elements:
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…
15
Rational
Proprietary and
Confidential
Class Name
Package Name
Review: Class and Package

What is a class?
What is a class?

A description of a set of objects that share the same
responsibilities, relationships, operations, attributes, and
semantics.

What is a package?
What is a package?

A general purpose mechanism for organizing elements into
groups

A model element which can contain other model elements
16
Rational
Proprietary and
Confidential

Group Design Classes In Packages

When identifying classes, they should be grouped into
When identifying classes, they should be grouped into
Artifact: Design Package
Artifact: Design Package
s
s

You can base your packaging criteria on a number of
You can base your packaging criteria on a number of
different factors
different factors

Configuration

Allocation of resources among development teams

Reflect the user types

Represent the existing products and services the system uses
17
Rational
Proprietary and
Confidential
Packaging Tips: Boundary Classes
If it is likely the system interface will
undergo considerable changes
Boundary classes placed in
separate packages

If it is unlikely the system interface will
undergo considerable changes
Boundary classes packaged
With functionally related classes
18
Rational
Proprietary and
Confidential
Packaging Tips: Functionally Related Classes

Criteria for determining if classes are functionally related
Criteria for determining if classes are functionally related

Changes in one class’ behavior and/or structure necessitate
changes in anther 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
19
Rational
Proprietary and

Confidential
Packaging Tips: Functionally Related Classes(cont.)

Criteria for determining if classes are functionally related
Criteria for determining if classes are functionally related
(continued)
(continued)

Two classes have relationships between each other

One class creates instances of another class
One class creates instances of another class

Criteria for determining when two classes should NOT be
Criteria for determining when two classes should NOT be
placed in the same package
placed in the same package

Two classes that are related to different actors should not be
placed in the same package
20
Rational
Proprietary and
Confidential
PackageB
+Class B1
-Class B2
PackageA
Class A1
Class A3

Class A2
A
B
Public visibility
Private visibility
Only public classes
can be referenced
outside of the
owning package
OO Principle: Encapsulation
Package Dependencies: Package Element Visibility
21
Rational
Proprietary and
Confidential
Package Coupling: Tips

Packages should not
Packages should not
be cross-coupled
be cross-coupled

Packages in lower
Packages in lower
layers should not be
layers should not be
dependent upon
dependent upon
packages in upper
packages in upper

layers
layers

In general,
In general,
dependencies should
dependencies should
not skip layers
not skip layers
A
B
A
B
C
Upper Layer
Lower Layer
22
Rational
Proprietary and
Confidential
RegistrationController
<<control>>
MainStudentForm
RegisterForCoursesForm
<<boundary>>
1
1
1
0 1
CloseRegistrationController

<<control>>
MainRegistrarForm
CloseRegistrationForm
<<boundary>>
1
1
1
0 1
Example: Registration Package
23
Rational
Proprietary and
Confidential
FulltimeStudent
<<entity>>
ParttimeStudent
<<entity>>
PrimaryScheduleOfferingInfo
<<entity>>
ScheduleOfferingInfo
<<entity>>
Student
<<entity>>
Course
<<entity>>
Professor
<<entity>>
Schedule
<<entity>>
CourseOffering

<<entity>>
CourseOfferingList
1
preRequisites
0 *
0 *
1
instructor
0 1
0 *
0 *0 *
0 *
0 4
primaryCourses
0 *
0 2
alternateCourses
0 *
1
Example: University Artifacts Package
24
Rational
Proprietary and
Confidential
IBillingSystem
<<Interface>>
ICourseCatalogSystem
<<Interface>>
Example: External System Interfaces Package
25

Rational
Proprietary and
Confidential
Subsystem and Interface

A subsystem is a model element which has the
A subsystem is a model element which has the
semantics of a package, such that it can contain
semantics of a package, such that it can contain
other model elements, and a class, such that it
other model elements, and a class, such that it
has behavior
has behavior

A subsystem realizes one or more interfaces,
A subsystem realizes one or more interfaces,
which define the behavior it can perform
which define the behavior it can perform



A subsystem may be represented as a a UML
A subsystem may be represented as a a UML
package (e.g., a tabbed folder) with the
package (e.g., a tabbed folder) with the
«subsystem» stereotype
«subsystem» stereotype