5 transition to design

1

Transition to Design

2

How is Design Different from Analysis? Design states "how the system will be constructed without actually

building it" (Rumbaugh, 1997)

Phân tích Thiết kế

Xác định hệ thống phải làm “cái gì” (what)

Chỉ ra hệ thống phải thực hiện điều đó như thế nào (how)

Tìm hiểu tổ chức, xác định yêu cầu và mục tiêu của tổ chức.

Xác định một hệ thống phù hợp với tổ chức, đáp ứng các yêu cầu của tổ chức một cách hiệu quả, và hỗ trợ tổ chức đạt được mục tiêu của nó.

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.

3

Identify Design Elements

4

Objectives: Identify Design Elements 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

6

SupplementarySpecifications

Identify Design

Elements

SoftwareArchitectureDocument

Design Model

Analysis Model

Project SpecificGuidelines

Identify Design Elements Overview

7

Identify Design Elements Steps Identify classes and subsystems Identify subsystem interfaces Identify reuse opportunities Update the organization of the Design Model Checkpoints

8


Analysis Classes

9

From Analysis Classes to Design ElementsAnalysis Classes Design Elements

<<boundary>>

<<control>>

<<entity>>

<<boundary>>

Many-to-Many Mapping

Subsystem<<subsystem>>

Subsystem<<subsystem>>

10

Identifying Design Classes 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 Split into multiple classes Become a package Become a subsystem (discussed later) Any combination …

11

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? 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

12

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 usesPackage C

Group Design Classes in Packages

Package B

Package A

13

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

14

Packaging Tips: Functionally Related Classes Criteria for determining if classes are functionally

related: 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

15

Packaging Tips: Functionally Related Classes Criteria for determining if classes are functionally

related (continued): Two classes have relationships between each other One class creates instances of another class

Criteria for determining when two classes should NOT be 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

16

PackageB

PackageA

Public visibility

Private visibility

Only public classes can be referenced

outside of the owning package

OO Principle: Encapsulation

Package Dependencies: Package Element Visibility

A

B

+ Class A1

+ Class A2

+ Class A3

+ Class B1

- Class B2

17

A

B

X

Package Coupling: Tips

A B

Upper Layer

Lower Layer

C

X

X = Coupling violation

X Packages should not be

cross-coupled

Packages in lower layers should not be dependent upon packages in upper layers

In general, dependencies should not skip layers

21

Identifying Subsystems A sub-system typically groups together elements

of the system that share some common properties An OO sub-system encapsulates a coherent set of

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

Each subsystem has a well-defined interface with the rest of the system but does not describe its internal structure.

A sub-system can be designed and constructed independently of orther sub-systems.

22

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

Realizes one or more interfaces that define its behavior

Subsystem

Subsystems and Interfaces

InterfaceRealization (Canonical form)

Realization (Elided form)

Subsystem Name <<subsystem>>

Interface Name<<interface>>

Interface Name Subsystem Name <<subsystem>>

23

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()

<<Interface>>

SubsystemA<<subsystem>>

SubsystemB<<subsystem>>

ClassA1

W()

ClassA2

X()

ClassB1

W()Y()

ClassB2

X()

ClassB3

Z()

24

Packages versus Subsystems Subsystems

Provide behavior Completely encapsulate their

contents Are easily replaced

Packages 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

25

Subsystems raise the level of abstraction.

Subsystem Usage Subsystems can be used to partition the system

into parts 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

Subsystems can also be used to: 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)

26

Identifying Subsystems Hints Look at object collaborations. Look for optionality. Look to the user interface

of the system. Look to the actors. Look for coupling and cohesion between classes. Look at substitution. Look at distribution. Look at volatility.

27

Candidate Subsystems Analysis classes which may evolve into

subsystems: Classes providing complex services and/or utilities

(Security authorization services) Boundary classes (user interfaces and external system

interfaces) Existing products or external systems in the design

(e.g., components): Communication software (middle-ware, COM/CORBA

support) Database access support (RDBMS mapping support) Types and data structures (stacks, lists, queues) Common utilities (math libraries) Application-specific products (billing system, scheduler)

Subsystem A<<subsystem>>

Subsystem B<<subsystem>>

28

Identifying Subsystems

<<control>>ClassA

X()W()

X()W()

<<Interface>>

“Superman Class”

InterfaceK SubsystemA<<subsystem>>

ClassA1

X()

ClassA2

W()

29


30

Stable, well-defined interfaces are key to a stable, resilient architecture.

Identifying Interfaces Purpose

To identify the interfaces of the subsystems based on their responsibilities

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

31

Interface Guidelines Interface name

Reflects role in system

Interface description Conveys responsibilities

Operation definition Name should reflect operation result Describes what operation does, all parameters and result

Interface documentation Package supporting info: sequence and state diagrams, test

plans, etc.

32All other analysis classes map directly to design classes.

Analysis Design

Example: Design Subsystems and Interfaces

BillingSystem

//submit bill()

<<boundary>>

Billing System<<subsystem>>

IBillingSystem

submitBill(forTuition : Double, forStudent : Student)

CourseCatalogSystem

//get course offerings()

<<boundary>>

Course Catalog System <<subsystem>>

ICourseCatalogSystem

getCourseOfferings(forSemester : Semester, forStudent : Student) : CourseOfferingListinitialize()

33

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

Analysis Class Design Element

CourseCatalogSystem CourseCatalogSystem Subsystem

BillingSystem BillingSystem Subsystem

All other analysis classes map directly to design classes

34

Interfaces start with an “I”

Modeling Convention: Subsystems and Interfaces

CourseCatalogSystem<<subsystem>>

+ initialize ()+ getCourseOfferings ()

ICourseCatalogSystem<<interface>>

+ getCourseOfferings () + initialize ()


ICourseCatalogSystem + initialize ()+ getCourseOfferings ()

35

Provided interfacedefined

ICourseCatalogSystem<<Interface>>

CloseRegistrationController

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

<<control>>

0..1

+courseCatalog


+ initialize ()+ getCourseOfferings ()

+ getCourseOfferings (forSemester: Semester) + initialize ()

RegistrationController

+ getCurrentSchedule()+ deleteCurrentSchedule()+ submitSchedule()+ saveSchedule()+ getCourseOfferings()+ setSession()+ <<class>> new()+ getStudent()

<<control>>

CourseOfferingList

+ new()+ add()

1

Required interfacedefined

Example: Subsystem Context: CourseCatalogSystem

36

IBillingSystem

+ submitBill(forStudent : Student, forTuition : double)

<<Interface>>

1

0..1

+ Biller

Student<<entity>>

CloseRegistrationController

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

<<control>>

BillingSystem<<subsystem>>

+ submitBill(forStudent : Student, forTuition : double)

Example: Subsystem Context: Billing System

37


38

Identification of Reuse Opportunities Purpose

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

Steps Look for similar interfaces Modify new interfaces to improve the fit Replace candidate interfaces with existing interfaces Map the candidate subsystem to existing components

39

Possible Reuse Opportunities Internal to the system being developed

Recognized commonality across packages and subsystems

External to the system being developed Commercially available components Components from a previously developed application Reverse engineered components

Software

Software

Software

Software

?

Reuse Opportunities Internal to System

41

Identify classes and subsystems Identify subsystem interfaces Identify reuse opportunities Update the organization of the Design Model Checkpoints

ClassB

Y()Z()

ClassA

Y()Z()

ClassC

Y()Z()

ClassD

Y()Z()

ClassC

Y()Z()

ClassE

Y()Z()

Identify Design Elements Steps

42

Software Architecture A software architecture is a description of the sub-systems

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

The architecture of the information system is first considered early in the project during the requirements capture and analysis activities.

We will consider some of the major architecture styles Client/Server Architecture Peer-to-Peer Architecture Layered Architecture Model/View/Controller

43

The server sub-system does not depend on the client sub-system and is not affected by changes to the client’s interface.

«client»Sub-system A

«server»Sub-system B

«peer»Sub-system D

«peer»Sub-system C

Each peer sub-system depends on the other and each is affected by changes in the other’s interface.

Styles of sub-system communication

44

Layering and Partitioning Two general approaches to the division of a

software 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

Both approaches are often used together on one system

45

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 1Layer 2

Layer N-1 Layer N

Layer 1Layer 2

Layer N-1 Layer N

46

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.

ApplicationApplication

Business-SpecificBusiness-Specific

MiddlewareMiddleware

System SoftwareSystem Software

47

Three & Four Layer Architectures.

Business logic layer can be split into two

layers

Database Access

Business Logic

Presentation

Database Access

Domain

Application logic

Presentation

48

Goal is to reduce coupling and to ease maintenance effort.

Layering Considerations Visibility

Dependencies only within current layer and below

Volatility (Tính có thể thay đổi) Upper layers affected by requirements changes Lower layers affected by environment changes

Generality More abstract model elements in lower layers

Number of layers Small system: 3-4 layers Complex system: 5-7 layers

49

Layer 1

Layer 2

Layer 3

Design Elements and the Architecture

50

Example: Architectural Layers

Middleware<<layer>>

Base Reuse

global

Application<<layer>>

Business Services

<<layer>>

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

51

Partitioning Considerations Coupling and cohesion User organization Competency and/or skill areas System distribution Secrecy Variability

Try to avoid cyclic dependencies.

52

Example: Partitioning

B

A Package A

Package B

53

Registration

<<layer>>Application

Example: Application Layer

54

Security

GUI FrameworkSecure Interfaces

Application<<layer>>

Business Services

<<layer>>

<<layer>>Application

<<layer>>Business Services

University Artifacts

Registration

External System Interfaces

Example: Application Layer Context

55

Example: Business Services Layer




ObjectStore Support


GUIFramework

SecureInterfaces

Security

<<subsystem>>SecurityManager


Example: Business Services Layer Context

Middleware<<layer>>

Business Services

<<layer>>

java.sqlcom.odi

<<layer>>Middleware





ObjectStore Support


GUIFramework

SecureInterfaces

Security

<<subsystem>>SecurityManager

57

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

58


59

Checkpoints General

Does it provide a comprehensivepicture of the services of different packages?

Can you find similar structural solutions that can be used more widely in the problem domain?

Layers Are there more than seven layers?

Subsystems Is subsystem partitioning done in a logically consistent way

across the entire model?

60

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?

61

Checkpoints (continued) Classes

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?

62

Review: Identify Design Elements What is the purpose of Identify Design Elements? What is an interface? What is a subsystem? How does it differ from a

package? What is a subsystem used for, and how do you

identify them? What are some layering and partitioning

considerations?

5 transition to design

Technology