單元 3 ：軟體設計 3-3 架構設計 Architecture Design – Decomposing the System

單元 3 ：軟體設計3-3 架構設計 Architecture Design –

Decomposing the System

Outline

• Introduction– OOSE Process– Why System Design

• System design activities: Decomposing the System– Define Design Goals– Define Subsystems

2

Software life cycle

3

Software life cycle

Development cycle

DesignImplementation Testing

Maintenance

RequirementsEngineering

System design

Object design

RequirementsSpecification

Analysis Model SDD

RequirementsElicitationAnalysis

Elicitation

System design

4

SDD

Analysis Model

Analysis

System design

Nonfunctional requirements

Dynamic model (Sequence diagrams)

Analysis object model (Class diagrams)

Design goals

Subsystem decomposition (Class diagrams)

Requirements Specification

Function model (Use case)

Requirements elicitation


Problem Statement

Objectives

Object design model (Class diagram)

Object design

Problem statement

• Problem

• Objectives

• Functional requirements

• Nonfunctional requirements

• Target environment

5

Objectives

• 建立一個教學網站系統，藉由此系統老師及助教可以很容易對於課程教材、學生資料以及作業、報告及成績等進行輕鬆的控管。學生可利用系統進行教材的下載，成績查詢等功能。

• 老師，助教及學生也可以利用系統進行互相討論課業及互相聯絡的進階功能。

• 教學網站為一個線上的系統 , 使用者可透過網頁瀏覽器對教學網站進行管理 , 使用 .

• ...

• ...

6

Nonfunctional Requirements

• Extensibility– 要在教學網站加入新功能時，不需要變更現有的系統架構

• Scalability– 系統必須讓多個作業能同時進行繳交和下載，並且作業上傳功能要在 50 位學生使用的狀況下正常連線與執行

• Low-bandwidth network– 學生只要有傳輸速率 56K/s 以上的 modem 就可以正常使用教學網站所有功能 7

Software Requirements Specifications

1. Introduction1.1 Purpose1.2 Scope1.3 Definitions, acronyms, and abbreviations1.4 References1.5 Overview

2. Overall description2.1 Product perspective2.2 Product functions2.3 User characteristics2.4 Constraints2.5 Assumptions and dependencies

3. Specific requirements3.1 External interface requirements3.2Functional requirements3.3Performance requirements3.4Design constraints3.5 Software system attributes

AppendicesIndex 8

Nonfunctional Requirements

Category Nonfunctional requirements

可靠度(Reliability)

若 Server shut down 則必須在 40 分鐘內恢復運作

效能(Performance)

系統必須讓多個作業能同時進行繳交和下載，並且作業上傳功能要在 50 位學生使用的狀況下正常連線與執行學生只要有傳輸速率 56K/s 以上的 modem 就可以正常使用教學

網站所有功能 .

系統實做(Implementation)

只要安裝有支援 cookies, Javascript, 瀏覽器的使用者都要可以使用教學網站教學網站要可以在 windows server 2000 + IIS +SQL Server 2000

上安裝在執行包裝(Packaging)

敎學網站除了提供服務以外，也要作為軟體工程課程的實例。教學網站的需求和設計要簡單容易講解

9

Analysis Model

10

Items

Models

Purpose Representation

Object model Specifying properties and relationship of individual concepts that are manipulated by the system.

( 指出系統的所有物及關係 )

Class diagrams

Dynamic model Representing the behaviors and interactions among a set of objects.

( 表示出物件間的行為及互動 )

Sequence diagrams

Object Model

11

Assignment

namecontextDue date

CreateAssignmentForm

createAssignment()set(….)

CreateAssignmentControl

check(…)

Dynamic Model

12

老師建立作業()

«new»

建立作業 Form

建立作業Control

作業

輸入 ( 名稱 , 要求 , 截止日期 )

檢查 (..)

«new»

System Design Document

Contents

1. Introduction1.1 Purpose of the system

1.2 Design goals

2. Software Architecture 2.1 Overview

2.2 Subsystem decomposition

2.3 Hardware/software mapping

2.4 Persistent data management

2.5 Access control and security

2.6 Global software control

2.7 Boundary conditions

3. Glossary and References 13

Object model and

Why System Design

• During system design, developers define the design goals of the project and decompose the system into smaller subsystems that can be realized by individual teams.( 定義 design goal以及將系統分解成較小的子系統，讓每個成員都能了解系統

的細部架構 ) • Developers also select strategies for building the system

( 開發者也可藉此選擇良好的系統發展策略 )

– Hardware/software mapping– Persistent data management– Global control flow– Access control policy– Handling of boundary conditions

14

System design activities

15

System design ：Decomposing the System

Design goals

Define design goals

Define subsystems

System Design Document

Subsystem decomposition


Requirements Specification

Function model (Use case)

Concept

Architectural

Analysis Model

Dynamic model

Analysis object model


Problem Statement

Objectives

Design Trade-offs

• When defining design goals, only a small subset of these criteria can be simultaneously taken into account. ( 定義 design goals 時 , 只有小部分的準則能同時被考慮到 -必須做取捨 )

• Developers need to prioritize design goals and trade them off against each other as well as against managerial goal as the project runs behind schedule or over budget. ( 開發者必須考量 design goals彼此之間的優先序，以及design goals 和 managerial goal之間的取捨 )

16

Design criteria• 效能

系統效能 . 系統執行的速度和所需的空間– Response time

系統回應使用者要求的時間– Memory

系統執行時所需消耗的記憶體大小

• 可靠性系統可靠性 . 系統能夠維持正常的執行不會發生錯誤及安全性問題– Robustness ( 強壯 )

乘載使用者的能力– Availability

系統正常運作的百分比– Fault tolerance

在不正常的狀況下進行作業的能力

17

成本 ( 低成本 )系統設計、開發、維護和管理時所需花費的成本維護系統的維護和變更

Extensibility系統功能的擴充能力Modifiability系統功能修改的難易度Readability程式碼的可讀性

使用者需求使用者端所要求的品質，系統是否好用、提供的功能是否符合使用者需要

Examples of design goal trade-offs• Rapid development vs. Functionality

( 快速地開發或者是提供功能強大的系統 )• Cost vs. speed

( 系統要有較高的 response 或 through put就需要更多的硬體成本 )

• Delivery time vs. functionality( 如果開發進度落後， project manager要在先提供功能未完整的版本或延後交貨時間補足功能做取捨。例如在作業截止前，尚未完成所有要求時，要考慮繳交屍體或遲交 )

• Delivery time vs. quality( 如果測試進度落後， project manager 要在時限內提供有 bug 的軟體版本推出後再進行 patch 或者修正 bug 延後交貨做取捨。例如微軟作業系統，推出後再針對 bug 發布更新檔 )

Managerial goals can be traded off against technical goals. 18

Define Design Goals-TeachingSite

19

Trade-offs

Problem Statement － Nonfunctional requirements

Requirements Specification － Nonfunctional requirements

Design criteria

Design goal ：容易增加新功能使用者數量的規模擴充性發展流程文件化符合 ISO/IEC 12207 軟體開發流程低成本

ExtensibilityScalability Packaging Cost

TeachingSite Design Goal

– 容易增加新功能網路服務不斷地精進和多樣化，硬體也不斷進步 . 教學網站如果要持續運作的話 , 必須要相容並容易增加新功能 .

– 使用者數量的規模擴充性Response time 不會因為使用者增加而降低品質 . 必要時可以新增硬體以維護連線品質 .

– 發展流程文件化教學網站發展過程中所產生的文件完全保留 , 以利眾人開發 .

– 符合 ISO/IEC 12207 軟體開發流程教學網站最主要的目的是作為軟體工程的實際範例 . 因此 ,本系統必須容易建立和部署以利於初學者學有機會學習如何解決複雜的設計問題 .

– 低成本硬體資源、網路資源和管理等支出最小化 . 20

Façade Design Pattern

• Intent– Provide a unified interface to a set of interfaces in a subsystem. Facade defines

a higher-level interface that makes the subsystem easier to use.( 在較高層的 subsystem提供一個統一介面對底層的 subsystem進行整合，以便於使用低層 subsystem)

• Benefits– Reducing the number of objects that clients deal with and making the

subsystem easier to use.( 減少 clients所需要應付的 Objects數量 , 讓 subsystem更容易使用 )

– It promotes weak coupling between the subsystem and its clients. Weak coupling lets you vary the components of the subsystem without affecting its clients.( 在 subsystem和它的 client之間產生 weak coupling. Weak coupling讓你在變更 subsystem內的 components時不會對 clients造成影響 ) 21

Subsystem• Subsystem:

– Collection of classes, associations, operations, events and constraints that are interrelated

(具有相互關係 ,各自 operations 的 class 所組合而成的集合 )– Seed for subsystems: UML Objects and Classes.

(subsystems 是由 Objects 和 Classes 所構成 )• (Subsystem) Service:

– Group of operations provided by the subsystem

(Subsystem 所提供的操作群組 )– Services are defined in System Design– 作業管理所提供的 service:

• 新增作業、修改作業、刪除作業、檢視作業22

Coupling and Cohesion• Cohesion measures the dependence among classes.

( 子系統內類別之間的相依性 )– High cohesion: The classes in the subsystem perform similar

tasks and are related to each other.( 子系統內的 classes工作類似互為相關 )

• Coupling measures dependencies between subsystems.( 子系統之間的相依性 )– Low coupling: A change in one subsystem does not affect any

other subsystem.( 變更一個子系統時不會對其他子系統造成影響 )

• Subsystems should have as maximum cohesion and minimum coupling as possible.(最大的 cohesion 和最小的 coupling)

23

Example: Subsystem

24

使用者管理

使用者

助教

學生

課程管理

課程

課程公告

老師

講義

作業分組作業

個人作業

作業管理

Software Architectural Styles

• Subsystem decomposition– Identification of subsystems, services, and their relationship to each other.

• Specification of the system decomposition is critical.• Patterns for software architecture

– Repository(倉儲 )– Client/Server– Layers– Three-tier– Others (Pipes and Filters, MVC).

25

Repository model• Subsystems must exchange data. This may be done in two ways:

– Shared data is held in a central database or repository and may be accessed by all sub-systems; ( 共有資料庫 )

– Each sub-system maintains its own database and passes data explicitly to other sub-systems. ( 個別資料庫 )

• The majority of system that use large amounts of data are organised around a shared DB or repository.

26

Subsystem

Repository

createData()setData()getData()searchData()

Client/Server Architectural Style

• One or many servers provides services to instances of subsystems, called clients.(Server提供服務給其他名為 clients的 subsystem)

• Client calls on the server, which performs some service and returns the result – Client knows the interface of the server (its service)

(Client知道 server的介面 )

– Server does not need to know the interface of the client (Server不需要知道 client的介面 )

27

Client

Server

service1()service2()

serviceN()…

**

requester provider

Layer architectural style

• A layer is a subsystem that provides subsystem services to a higher layers (layer的 subsystem對 higher layers提供 subsystem services)– A layer can only depend on lower layers

( 每個階層只會相依於較低層 )

– A layer has no knowledge of higher layers( 每個階層對上層一點都不了解 ) 28

F:SubsystemE:Subsystem G:Subsystem

D:SubsystemC:SubsystemB:Subsystem

A: Subsystem Layer 1

Layer 2

Layer 3

Three-tier architectural style

• The Three-tier architectural style organizes subsystems into three layers– The Presentation layer includes all boundary objects that deal

with the user.– The Business logic layer includes all control and entity objects.– The Data layer realizes the storage, retrieval, and query of

persistent object.

29

Presentation

Business logic

Data

Form

Connection

Query

System architecture

30

Data

使用者 1 使用者 2

作業管理

Presentation

Business Logic

使用者管理

教學網站服務窗口

教學網站網頁介面

課程管理

Repository

檔案系統資料庫

Repository model

Client

Server

教學網站資料管理

Choosing Subsystems• Criteria for subsystem selection: Most of the interaction should be within

subsystems, rather than across subsystem boundaries (High cohesion).(Subsystem挑選的準則 : 大部分的交互作用必須在 subsystems內 , 而不是橫跨數個 subsystem邊界 .)

• Heuristics for grouping objects into subsystems– Assign objects identified in one use case into the same subsystem.( 將一個 use case內的 objects分配至相同的subsystem.)

– All objects in the same subsystem should be functionally related.( 相同 subsystem內的 objects有功能上的關係 )

– Minimize the number of associations crossing subsystem boundaries. ( 將 subsystem對外界的連結最小化 )

– …

31

Subsystem Decomposition Example- TeachingSite

• TeachingSite functional requirements (top level use case)

Administrator

Teacher

Player

TA

ManageUser Accounts

DefineCourse

ManageCourse

Upload/DownloadAssignment

ManageOwnProfile

ViewOwnGrade

ManageAssignment

<< include>>

32

Subsystem Decomposition Example- TeachingSite

• The initial subsystem decomposition– 根據 functional requirement 對 system 做 partition

33教學網站資料管理

課程管理

作業管理

使用者管理

Subsystem Decomposition Example-TeachingSite

• Refine the subsystem decomposition to address the design goals– According to

• TeachingSite Objective– 建立一個教學網站系統，藉由此系統老師及助教可以很容

易 .....

• TeachingSite Design Goal

– Use• Three-tier architectural

• Facade Design Pattern

34


• Design Goal：

– 容易增加新功能網路服務不斷地精進和多樣化，硬體也不斷進步 . 教學網站如果要持續運作的話 ,必須要相容並容易增加新功能 .

– 使用者數量和現存課程的規模擴充性Response time 不會因為使用者增加而降低品質 . 必要時可以新增硬體以維護連線品質 .

– 發展流程文件化教學網站發展過程中所產生的文件完全保留 , 以利眾人開發 .

– 教學範例教學網站最主要的目的是作為軟體工程的實際範例 . 因此 , 本系統必須容易建立和部署以利於初學者學有機會學習如何解決複雜的設計問題 .

– 低成本硬體資源、網路資源和管理等支出最小化 .

35


36

使用者 1

使用者管理

使用者 2

Data

Business Logic

使用者網頁介面課程網頁介面

作業管理


課程管理

Presentation


37

使用者管理



使用者網頁介面課程網頁介面

課程管理教學網站服務窗口


作業管理

Data

Business Logic

Presentation

TeachingSite Subsystem Decomposition

38

使用者管理



課程管理教學網站服務窗口


作業管理

Data

Business Logic

Presentation

單元 3 ：軟體設計 3-3 架構設計 Architecture Design – Decomposing the System

Documents

Transcript of 單元 3 ：軟體設計 3-3 架構設計 Architecture Design – Decomposing the System