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

Outline Introduction System design activities: Decomposing the System OOSE Process Why System Design System design activities: Decomposing the System Define Design Goals Define Subsystems

Software life cycle Software life cycle Development cycle Requirements Engineering Design Implementation Testing Requirements Elicitation System design Analysis Elicitation Object design Requirements Specification Analysis Model SDD Maintenance

System design Problem Statement Objectives Requirements elicitation Nonfunctional requirements Requirements Specification Analysis Function model (Use case) Nonfunctional requirements Analysis Model Analysis object model (Class diagrams) Nonfunctional requirements => Activity 1: Design Goals Definition Functional model => Activity 2: System decomposition (Selection of subsystems based on functional requirements, cohesion, and coupling) Object model => Activity 4: Hardware/software mapping Activity 5: Persistent data management Dynamic model => 　Activity 3: Concurrency Activity 6: Global resource handling Activity 7: Software control Subsystem Decomposition Activity 8: Boundary conditions Dynamic model (Sequence diagrams) System design SDD Design goals Subsystem decomposition (Class diagrams) Object design Object design model (Class diagram)

Problem statement Problem Objectives Functional requirements Nonfunctional requirements Target environment

Objectives 建立一個教學網站系統，藉由此系統老師及助教可以很容易對於課程教材、學生資料以及作業、報告及成績等進行輕鬆的控管。學生可利用系統進行教材的下載，成績查詢等功能。 老師，助教及學生也可以利用系統進行互相討論課業及互相聯絡的進階功能。 教學網站為一個線上的系統, 使用者可透過網頁瀏覽器對教學網站進行管理,使用. ...

Nonfunctional Requirements Extensibility 要在教學網站加入新功能時，不需要變更現有的系統架構 Scalability 系統必須讓多個作業能同時進行繳交和下載，並且作業上傳功能要在50位學生使用的狀況下正常連線與執行 Low-bandwidth network 學生只要有傳輸速率56K/s以上的modem就可以正常使用教學網站所有功能

Software Requirements Specifications 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, acronyms, and abbreviations 1.4 References 1.5 Overview 2. Overall description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 Constraints 2.5 Assumptions and dependencies 3. Specific requirements 3.1 External interface requirements 3.2 Functional requirements 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes Appendices Index

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

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

CreateAssignmentForm Object Model CreateAssignmentControl check(…) Assignment name context Due date CreateAssignmentForm createAssignment() set(….)

Dynamic Model 建立作業Form 建立作業() 建立作業 Control 作業 老師 «new» 輸入(名稱,要求, 截止日期) 檢查(..)

System Design Document Contents 1. Introduction 1.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 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 1.開發者定義出計畫的設計目標，並將系統分解成能讓每個成員所明瞭的子系統 2.開發者也可以藉此選擇系統發展時的策略方向 H/S 策略、永久性資料管理策略、全域控制流程、存取控制策略、邊界狀態處理(初始化、開始、結束) 以上策略會在下一個章節做介紹

System design activities Problem Statement Objectives Nonfunctional requirements System design： Decomposing the System Requirements Specification Define design goals Nonfunctional requirements Function model (Use case) Define subsystems Analysis Model Concept Analysis object model Architectural Dynamic model System Design Document Design goals Subsystem decomposition

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之間的取捨) 何謂managerial goal? 意指管理方面的目標嗎

Design criteria 效能 可靠性 Response time Memory Robustness (強壯) 系統效能. 系統執行的速度和所需的空間 Response time 系統回應使用者要求的時間 Memory 系統執行時所需消耗的記憶體大小 可靠性 系統可靠性. 系統能夠維持正常的執行不會發生錯誤及安全性問題 Robustness (強壯) 乘載使用者的能力 Availability 系統正常運作的百分比 Fault tolerance 在不正常的狀況下進行作業的能力 成本 (低成本) 系統設計、開發、維護和管理時所需花費的成本 維護 系統的維護和變更 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.

Define Design Goals-TeachingSite Problem Statement － Nonfunctional requirements Requirements Specification － Nonfunctional requirements Design criteria Trade-offs Extensibility Scalability Cost Packaging Design goal： 容易增加新功能 使用者數量的規模擴充性 發展流程文件化 符合ISO/IEC 12207軟體開發流程 低成本

TeachingSite Design Goal 容易增加新功能 網路服務不斷地精進和多樣化，硬體也不斷進步.教學網站如果要持續運作的話,必須要相容並容易增加新功能. 使用者數量的規模擴充性 Response time不會因為使用者增加而降低品質. 必要時可以新增硬體以維護連線品質. 發展流程文件化 教學網站發展過程中所產生的文件完全保留,以利眾人開發. 符合ISO/IEC 12207軟體開發流程 教學網站最主要的目的是作為軟體工程的實際範例. 因此,本系統必須容易建立和部署以利於初學者學有機會學習如何解決複雜的設計問題. 低成本 硬體資源、網路資源和管理等支出最小化.

Façade Design Pattern Intent Benefits 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造成影響)

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: 新增作業、修改作業、刪除作業、檢視作業 評斷如何選擇subsystem 選取相關性高classes 關係 或是 功能等等集合成一個subsystem 而選取一個subsystem最重要的地方在於 內部互動性高而不要與未選取之外部物件存取性高 這個關係我們後面會介紹 cohesion 以及 coupling

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) Cohesion (結合) : ko’hi sion Coupling ‘Kupling Goal: Reduction of complexity while change occurs 高度的cohesion 可以讓單一一個subsystem專心的做事 不會說做到一半就要跑出去要其他人的支援 相對於coupling 高度的coupling 代表說subsystem之間有高度關係所以牽一髮而動全身 : How can we achieve high cohesion? How can we achieve loose coupling?

Example: Subsystem 講義 課程公告 課程 學生 使用者 作業 分組作業 助教 老師 個人作業 課程管理 使用者管理 作業管理 作業 分組作業 助教 老師 coupling算法: Sum of subsystem’s relation/(N平方-N) Subsystem’s relation:直線=2,有箭號的=1, N: numbers of subsystem 計算結果為coupling百分比,分母是子系統之間相依性最大值， cohesion算法: Sum of class’/object’s relation/(N平方-N) class’/object’s relation:直線=2,有箭號的=1, N: numbers of class/object 計算結果為cohesion百分比,分母是子系統之間相依性最大值 實際狀況coupling跟cohesion都不可能大於1 個人作業

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). 剛剛都是講系統的架構分割 這邊講這邊是要來說明分割的系統中他們所提供的服務中的架構格式 可分為

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. 倉儲模型 系統中　子系統交換資料.會有有兩個方式: è讓子系統存取共享中央資料庫的資料 è每一個子系統維護自己的資料庫和並透過傳遞來達成資料交換 2.大多數的系統都會混用這兩種, 因為可能主要的資料都是由central DB提供子系統　增加系統控管 而也會有這樣的情況產生 A子系統所產生的資料 只要被B子系統使用 不希望被其他子系統所存取 所以需要自行建立DB來保護 倉儲模型特性 優點 1.有效的方式來分享大量資料,不需要在子系統間互相傳送資料 2.子系統需要遵循repository的資料傳輸方式(function 參數使用等等), 3.分享模式公開子系統不須考慮資料如何被其他子系統使用 缺點 1. 針對上面第二點 新增子系統時,子系統已經存在舊有的data model 會不符合repository的data model . 子系統若允許倉儲資料模型,會面臨不可避免的妥協,若資料模式不符合schema 整合子系統是不可能的(須完全符合才能做整合動作) 2. 因為集中的資料量太過於龐大了, 所以當evolution時如果轉換到新的系統可能會要採用不同的data model, 而工程浩大 甚至不太可能做到 3.Repository需要做備份 security 存取控制 以及錯誤回復(error recovery)造成 repository 負載過大 甚至他掛了 全部都不用作了。 4.會造成資料重複 或者不一致 很難去把倉儲分散到多個機器上,困難去分享沒有效率 (即使配置一個邏輯上集中式倉庫,卻會有資料重複或不一致的情形) Subsystems are loosely coupled (interact only through the repository) 相依性低 他們只會透過中央控管的repository存取資料 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的介面) Request通常會透過remote produce call mechanism 例如Java RMI or HTTP等等

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 (每個階層對上層一點都不了解)

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. Presentation Form Business logic Connection Data Query

System architecture Client Server Repository model Repository 使用者1 使用者2 Presentation Server 教學網站網頁介面 Business Logic 教學網站服務窗口 使用者管理 課程管理 作業管理 Repository model Data Repository 教學網站資料管理 資料庫 檔案系統

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對外界的連結最小化) …

Subsystem Decomposition Example- TeachingSite TeachingSite functional requirements (top level use case)

Subsystem Decomposition Example- TeachingSite The initial subsystem decomposition 根據functional requirement對system做partition 使用者管理 課程管理 作業管理 Notification(通知書) 負責註冊功能的subsystem? 教學網站資料管理

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

Subsystem Decomposition Example- TeachingSite Design Goal： 容易增加新功能 網路服務不斷地精進和多樣化，硬體也不斷進步.教學網站如果要持續運作的話,必須要相容並容易增加新功能. 使用者數量和現存課程的規模擴充性 Response time不會因為使用者增加而降低品質. 必要時可以新增硬體以維護連線品質. 發展流程文件化 教學網站發展過程中所產生的文件完全保留,以利眾人開發. 教學範例 教學網站最主要的目的是作為軟體工程的實際範例. 因此,本系統必須容易建立和部署以利於初學者學有機會學習如何解決複雜的設計問題. 低成本 硬體資源、網路資源和管理等支出最小化. Design Goal： Design Goal: Documentation for open source development ARENA game framework 程式碼及相關文件完全公開，以利眾人開發 Design Goal: Ease of adding new games This design goal is a refinement of the nonfunctional requirement ?extensibility? in the ARENA problem statement. Design Goal: High availability The value of an Arena increases with the number of players available for playing tournaments.This design goal is not explicitly stated in the problem statement or the requirements, but is necessary if an Arena is to attract and keep a sufficiently large number of players. Design Goal: Low operating cost 廣告、硬體資源、網路資源和管理等資支出最小化。This design goal is a refinement of the nonfunctional requirement ?low operating cost? of the ARENA problem statement Design Goal: Scalability in terms of number of players and concurrent tournaments Response time不會因為玩家增加而降低品質。必要時可以新增硬體以維護連線品質。 This design goal is a refinement of the nonfunctional requirement ?scalability? in the ARENA problem statement. Design Goal: Teaching example ARENA最主要的目的是作為OOSE的實際範例。 因此，本系統必須容易建立和部署以利於初學者學有機會學習如何解決複雜的設計問題。(e.g., scalability).

Subsystem Decomposition Example- TeachingSite 使用者1 使用者2 Presentation Data Business Logic 使用者網頁介面 課程網頁介面 使用者管理 課程管理 作業管理 教學網站資料管理

Subsystem Decomposition Example-TeachingSite 使用者1 使用者2 Presentation Data Business Logic 使用者網頁介面 課程網頁介面 教學網站網頁介面 教學網站服務窗口 課程管理 使用者管理 作業管理 教學網站資料管理

TeachingSite Subsystem Decomposition 使用者1 使用者2 Presentation Data Business Logic 教學網站網頁介面 教學網站服務窗口 課程管理 使用者管理 作業管理 教學網站資料管理