4-Transition to design.ppt

Objectives: Identify Design Elementsdemonstrate where in the lifecycle it is performed Model elements  Design classes  Subsystems  Subsystem interfaces...  You can base your packagin

Transition to Design

How is Design Different from Analysis?

 Ví dụ, trong Library case study:

 Phân tích xác định rằng lớp Book có thuộc tính title

 Thiết kế xác định thuộc tính title được lưu trữ vào hệ thống như thế nào, hiển thị trên màn hình và lưu trữ trong cơ sở dữ liệu như thế nào.

Khi nào phân tích kết thúc, thiết kế bắt đầu?

 Phân tích và thiết kế được xem là các hành động (Activity) phải thực hiện bên trong quy trình phát triển

 Phân tích một phần cụ thể của hệ thống sẽ phải thực hiện trước thiết kế của nó,

 Nhưng phân tích và thiết kế có thể thực hiện song song

chúng.

 Chúng ta luôn cần biết ‘what’ trước khi quyết định "how"

Identify Design Elements

Objectives: Identify Design Elements

demonstrate where in the lifecycle it is performed

Model elements

 Design classes

 Subsystems

 Subsystem interfaces

[Early Elaboration Iteration] Iteration (Optional)][Inception

Define a Candidate Architecture ArchitecturalPerform

Synthesis

Analyze Behavior

Refine the Architecture

Design Components Design theDatabase

Specifications

Identify Design Elements

Software Architecture Document

Design Model

Analysis Model

Project Specific Guidelines

Identify Design Elements Overview

Identify Design Elements Steps

Identify Design Elements Steps

Analysis Classes

From Analysis Classes to Design Elements

Analysis Classes 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

 Split into multiple classes

 Become a package

 Become a subsystem (discussed later)

 Any combination …

 What is a class?

 A description of a set of objects that share the same

responsibilities, relationships, operations, attributes, and semantics

 A general purpose mechanism for organizing elements into groups

 A model element which can contain other model elements

Review: Class and Package

Package Name Class Name

 You can base your packaging criteria on a number of

different factors, including:

 Configuration units

 Allocation of resources among development teams

 Reflect the user types

 Represent the existing products

and services the system uses Package C

Group Design Classes in Packages

Package B Package A

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

Packaging Tips: Functionally Related Classes

 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

Packaging Tips: Functionally Related Classes

(continued):

 Two classes have relationships between each other

 One class creates instances of another class

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

PackageB PackageA

Public visibility

Private visibility

Only public classes can be referenced outside of the owning package

+ Class B1

- Class B2

Lower Layer

 Packages in lower layers

should not be dependent

upon packages in upper

layers

 In general, dependencies

should not skip layers

Example: Registration Package

Example: University Artifacts Package

0 n 1

Example: External System Interfaces Package

<<Interface>>

Identifying Subsystems

system that share some common properties

responsibilities in order to ensure that it has integrity and can be maintained

of the system but does not describe its internal structure.

independently of orther sub-systems.

 Subsystems are a “cross between” a package (can contain other model elements) and a class (has behavior)

Subsystem

Review: Subsystems and Interfaces

Interface Realization (Canonical form)

Realization (Elided form)

Subsystem Name <<subsystem>>

Interface Name

<<interface>>

<<subsystem>>

Subsystems and Interfaces (continued)

 Subsystems :

 Completely encapsulate behavior

 Represent an independent capability with clear interfaces (potential for reuse)

 Model multiple implementation variants

InterfaceK

X() W()

ClassA2 X()

ClassB1

W() Y()

ClassB2 X()

ClassB3 Z()

Packages versus Subsystems

 Don’t provide behavior

 Don’t completely encapsulate their contents

 May not be easily replaced

Encapsulation is the key!

Subsystem A

<<subsystem>>

Package B ClassB1

ClassB2 Client Class

Subsystems raise the level of abstraction.

Subsystem Usage

that can be independently:

 ordered, configured, or delivered

 developed, as long as the interfaces remain unchanged

 deployed across a set of distributed computational nodes

 changed without breaking other parts of the systems

 partition the system into units which can provide restricted security over key resources

 represent existing products or external systems in the

design (e.g components)

Identifying Subsystems Hints

of the system.

Candidate Subsystems

 Classes providing complex services and/or utilities

 Boundary classes (user interfaces and external system interfaces)

components):

 Communication software

 Database access support

 Types and data structures

Identifying Subsystems

<<control>>

ClassA

X() W()

X() W()

<<Interface>>

“Superman Class”

InterfaceK <<subsystem>>SubsystemA

ClassA1 X()

ClassA2 W()

Identify Design Elements Steps

Stable, well-defined interfaces are key to a stable,

 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

 Name should reflect operation result

 Describes what operation does, all parameters and result

 Package supporting info: sequence and state diagrams, test plans, etc

All other analysis classes map directly to design classes.

Example: Design Subsystems and Interfaces

BillingSystem //submit bill()

<<boundary>>

Billing System

<<subsystem>>

IBillingSystem submitBill(forTuition : Double, forStudent : Student)

Example: Analysis-Class-To-Design-Element Map

CourseCatalogSystem CourseCatalogSystem

SubsystemBillingSystem BillingSystem Subsystem

All other analysis classes map

directly to design classes

Interfaces start with an “I”

Modeling Convention: Subsystems and Interfaces

CourseCatalogSystem

<<subsystem>>

+ initialize () + getCourseOfferings ()

ICourseCatalogSystem

<<interface>>

+ getCourseOfferings () + initialize ()

CourseCatalogSystem

<<subsystem>>

ICourseCatalogSystem + initialize ()

+ getCourseOfferings ()

deleteCurrentSchedule() + submitSchedule() + saveSchedule() + getCourseOfferings() + setSession()

+ <<class>> new() + getStudent()

<<control>>

CourseOfferingList

+ new() + add()

1

Required interface defined

Example: Subsystem Context: CourseCatalogSystem

<<entity>>

CloseRegistrationController

+ // is registration open?() + // close registration()

<<control>>

BillingSystem

<<subsystem>>

+ submitBill(forStudent : Student, forTuition : double)

Example: Subsystem Context: Billing System

Identify Design Elements Steps

Identification of Reuse Opportunities

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

 Look for similar interfaces

 Modify new interfaces to improve the fit

 Replace candidate interfaces with existing interfaces

 Map the candidate subsystem to existing components

Possible Reuse Opportunities

 Recognized commonality across packages and subsystems

 Commercially available components

 Components from a previously developed application

 Reverse engineered components

Softw are

Softw are Softw are

Softw are

Reuse Opportunities Internal to System

 Identify classes and subsystems

ClassB

Y() Z()

ClassA

Y() Z() ClassC

Y() Z()

ClassD Y() Z()

ClassC Y() Z()

ClassE Y() Z()

Identify Design Elements Steps

Software Architecture

and components of a software system and the relationships between them.

considered early in the project during the requirements capture and analysis activities.

 Client/Server Architecture

 Peer-to-Peer Architecture

 Layered Architecture

 Model/View/Controller

The server sub-system does

not depend on the client

sub-system and is not affected by

changes to the client’s interface.

in the other’s interface.

Styles of sub-system communication

Layering and Partitioning

system into sub-systems

 Layering – so called because the different sub-systems

usually represent different levels of abstraction

 Partitioning – which usually means that each sub-system

focuses on a different aspect of the functionality of the system as a whole

Schematic of a Layered Architecture

Closed architecture–

messages may only be

sent to the adjacent

lower layer

Open architecture–

messages can be sent

to any lower layer

Layer 1 Layer 2

Layer N-1 Layer N

Layer 1 Layer 2 Layer N-1 Layer N

Typical Layering Approach

General

functionality

Specific

functionality Distinct application subsystems that make

up an application — contains the value adding software developed by the organization.

Business specific — contains a number of reusable subsystems specific to the type of business.

Middleware — offers subsystems for utility classes and platform-independent services for distributed object computing in heterogeneous environments and so on.

System software — contains the software for the actual infrastructure such as operating systems, interfaces to specific hardware, device drivers, and so on.

Application

Business-Specific

Middleware

System Software

Three & Four Layer Architectures.

Business logic layer can be split into two layers

Goal is to reduce coupling and to ease maintenance effort.

Layering Considerations

 Dependencies only within current layer and below

 Volatility

 Upper layers affected by requirements changes

 Lower layers affected by environment changes

 More abstract model elements in lower layers

 Small system: 3-4 layers

 Complex system: 5-7 layers

Example: Architectural Layers

<<layer>>

Necessary because the Application Layer must have access to the core distribution mechanisms provided with Java RMI.

Example: Partitioning

B

A Package A

Package B

GUI Framework Secure Interfaces

Application<<layer>>

Business Services

Example: Application Layer Context

Example: Business Services Layer

CourseCatalogSystem

<<subsystem>>

External System Interfaces

University Artifacts

ObjectStore Support

<<layer>>

Business Services

GUI Framework

Secure Interfaces

Security

<<subsystem>> Security Manager BillingSystem

<<subsystem>>

Example: Business Services Layer Context

Middleware<<layer>>

Business Services

<<layer>>

java.sql com.odi

University Artifacts

Secure Interfaces

Security

<<subsystem>>

Security Manager

Example: Middleware Layer

com.odi

Database (from com.odi)

Session (from com.odi)

Transaction (from com.odi)

Map

(from com.odi)

java.sql

ResultSet (from com.odi)

Connection (from com.odi)

Statement (from com.odi)

DriverManager (from com.odi)

<<layer>>

Middleware

Identify Design Elements Steps

 Does it provide a comprehensive

picture of the services of different packages?

 Can you find similar structural solutions

that can be used more widely in the problem domain?

Checkpoints (continued)

 Packages

 Are the names of the packages descriptive?

 Does the package description match with

the responsibilities of contained classes?

 Do the package dependencies correspond to the

relationships between the contained classes?

 Do the classes contained in a package belong there

according to the criteria for the package division?

 Are there classes or collaborations of classes within a

package that can be separated into an independent package?

 Is the ratio between the number of packages and the

number of classes appropriate?

Checkpoints (continued)

 Does the name of each class clearly

reflect the role it plays?

 Is the class cohesive

(i.e., are all parts functionally coupled)?

 Are all class elements needed by the use-case realizations?

 Do the role names of the aggregations and associations

accurately describe the relationship?

 Are the multiplicities of the relationships correct?

Review: Identify Design Elements

them?