1 / 38

單元 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. Software life cycle. Software life cycle. Development cycle. Requirements

lixue
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

  4. System design Problem Statement Requirements elicitation Objectives Nonfunctional requirements Requirements Specification Analysis Function model (Use case) Nonfunctional requirements Analysis Model Analysis object model (Class diagrams) Dynamic model (Sequence diagrams) System design SDD Design goals Subsystem decomposition (Class diagrams) Object design Object design model (Class diagram)

  5. Problem statement • Problem • Objectives • Functional requirements • Nonfunctional requirements • Target environment

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

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

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

  9. Nonfunctional Requirements

  10. Analysis Model

  11. Object Model

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

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

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

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

  16. 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之間的取捨)

  17. Design criteria • 成本 (低成本) • 系統設計、開發、維護和管理時所需花費的成本 • 維護 • 系統的維護和變更 • Extensibility • 系統功能的擴充能力 • Modifiability • 系統功能修改的難易度 • Readability • 程式碼的可讀性 • 使用者需求 • 使用者端所要求的品質，系統是否好用、提供的功能是否符合使用者需要 • 效能 系統效能.系統執行的速度和所需的空間 • Response time 系統回應使用者要求的時間 • Memory 系統執行時所需消耗的記憶體大小 • 可靠性 系統可靠性. 系統能夠維持正常的執行不會發生錯誤及安全性問題 • Robustness (強壯) 乘載使用者的能力 • Availability 系統正常運作的百分比 • Fault tolerance 在不正常的狀況下進行作業的能力

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

  19. 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軟體開發流程 • 低成本

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

  21. 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造成影響)

  22. 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: • 新增作業、修改作業、刪除作業、檢視作業

  23. 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)

  24. Example: Subsystem 課程管理 課程公告 講義 課程 使用者管理 學生 作業管理 使用者 作業 分組作業 助教 老師 個人作業

  25. 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).

  26. Repository Subsystem createData() setData() getData() searchData() 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.

  27. 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的介面)

  28. Layer 1 Layer 2 Layer 3 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 (每個階層對上層一點都不了解)

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

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

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

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

  33. Subsystem Decomposition Example- TeachingSite • The initial subsystem decomposition • 根據functional requirement對system做partition 使用者管理 課程管理 作業管理 教學網站資料管理

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

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

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

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

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

More Related