Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chapter 10 Component-Level Design (基本OO設計原則 (其他原則 (REP (The Release Reuse…
Chapter 10 Component-Level Design
Component
定義 : a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces
元件設計
物件導向設計角度
定義 : A component contains a set of collaborating classes
基本設計概念
從analysis model開始，再Elaborate(Analysis classes、Infrastructure classes)
例子
影印店 : 收集客戶需求 → Cost a print job → 透過自動化生產設備完成工作
傳統結構化設計設計角度
定義 : 元件包含
processing logic
實作processing logic的內部資料結構
an interface that enables the component to be invoked and data to be passed to it
基本設計概念
從analysis model開始，通常使用DFD
把DFD轉換成結構圖
在結構圖中elaborate每個module(Control component、Problem domain component)
基本OO設計原則
OCP
(The Open-Closed Principle)
說明 : 模組(元件)應該要open for擴充，closed for修改
方法 : create
抽象化
，作為可擴展的功能與design class之間的buffer
LSP
(The Liskov Substitution Principle)
說明
“Subclasses should be substitutable for their base classes.”
若一個使用base class的元件被衍生class替代，則應該繼續正常運作
Example : 任何使用感測器class的類別，都應該要適用於特定感測器(e.g.煙霧偵測器)
DIP
(Dependency Inversion Principle)
說明
“Depend on abstractions. Do not depend on concretions.”
元件越依賴其他具體元件，則越難進行擴展
ISP
(The Interface Segregation Principle)
說明 : 多個client-specific interfaces better than 1個通用的interface
其他原則
REP
(The Release Reuse Equivalency Principle) : reuse的尺度就是release的尺度
CCP
(The Common Closure Principle) : “Classes that change together belong together.”
CRP
(The Common Reuse Principle) : “Classes that aren’t reused together should not be grouped together.”
OO-元件設計的guidlines
Component
: 命名要有意義，易讀、易維護
Interfaces
: 提供溝通、collaborate的重要資訊，推薦使用簡化的UML元件圖
圖變複雜時，建議使用lolipop表示
interface應該要從元件框的左邊流出
僅顯示元件、相關的interface
Dependencies and Inheritance
從左到右是dependency; 從下到上是繼承
透過interface來表示相互依賴性
Cohesion
(內聚)
傳統角度 : modular的一心一意
OO角度 : 只封裝與元件或class密切相關的屬性、operations
Coupling
(耦合性)
定義 : 元件與其他元件(or外部世界)的關聯度
目標 : 盡可能降低耦合性
Component Level Design
7個步驟
Step1. identify所有對應到問題domain的design class
Step2. identify所有對應到基礎架構domain的design class
Step3. Elaborate所有不能作為reuse元件的design class
Step3.a Specify class與元件collaborate時的message details
Step3.b 替每個元件identify合適的介面，檢查內聚力(cohesion)並進行重構
Step3.c Elaborate屬性、定義資料型態與資料結構for實作
Step3.d 詳細描述每個operation的處理流程。使用虛擬碼或UML activity diagram
Step4. 描述data sources (databases and files)、identify管理他們所需要的class
Step5. 替class或元件develop and elaborate行為表示 (使用UML statechart diagram)
Step6. Elaborate deployment diagrams(部署圖)以提供其他實作細節 (Specify硬體、OS)
Step7. Factory 每個component-level design表示，並總是考慮替代方案
表示
Collaboration Diagram
Message format : [guard condition] sequence expression (return value) := message name (argument list)
用途 : 可用於呈現在特定use case中，物件與物件之間是如何interact的
Attribute Type Defined
Type syntax : 屬性名稱 : 型別表達式 = 初始值 {可能的屬性的值}
Statechart
Transition form
Event-name (parameter-list)
[guard-condition]/action expression
(written in Object Constraint Lanaguage (OCL))
OCL
(Object Constraint Language)
使用正規語法來建立unambiguous statements，以補充UML
4 part
(1)
context
: 描述設計內容
(2)
property
: 描述context的屬性(e.g. 若context是class, property可為屬性)
(3)
operation
: 描述operation(類似虛擬碼)
(4)
keywords
: specify條件表達式的keywords(e.g. if, then, else, and, or, not, implies)