Transcript 下載/瀏覽Download

塑模元件層級設計
何謂元件？
以一般的方式來說，元件
(component)是電腦軟體的一個
模組建構方塊。
元件植基(populate)於軟體的
架構中，並且扮演達成所要建
造系統的目標與需求的角色。
「元件」這個專有名詞的真實
意義將視使用它的軟體工程師
的觀點而有所不同。
以物件為導向的觀點
在物件導向軟體工程的環境中，
一個元件包含一組合作的類別。
為完成此目標，設計者由分析
模型開始，並細化分析類別(對
相關於問題領域的元件)與基礎
建設類別(infrastructure
classes)(對問題領域提供支援
服務的元件)。
以傳統的觀點
在傳統的軟體工程環境中，一個元件是程
式的一個功能元件，它結合處理邏輯、必
須要實作處理邏輯的內部資料結構，和讓
元件可被召喚且資料可傳遞給它的介面。
傳統的元件也稱為模組(module)，它駐留
於軟體結構中，並做為三種重要的角色之
一：
控制元件(control component)
問題領域元件(problem domain
component)
基礎建設元件(infrastructure
component)
以流程相關的觀點
元件層級設計的物件導向與傳統的觀點均假設
元件從頭開始設計。
過去的十年中，軟體工程社群已經強調利用現
有的軟體元件建立系統的需要。
基本上，在設計工作進行時，軟體工程師可
以利用已證明的設計或編碼層級(code-level)
這類的元件目錄。
當軟體架構發展時，元件或設計模式可從此
目錄中選擇，並移往架構中使用。
因為這些元件在想法上已經產生出其可重複
使用性、一個完整描述的介面、它們所執行
的功能和它們所需要的通訊與細化，對設計
者都是可以利用的。
元件基本設計原則
四種基本的設計原則可應用於元件層級
的設計，且物件導向軟體工程被應用時，它
們一直受到廣泛的採用。
 開關原則(Open-Closed Principle,OCP)
 Liskov替換原則(The Liskov Substitution
Principle, LSP)
 相依倒轉原則(Dependency Inversion
Principle, DIP)
 介面隔離原則(Interface Segregation
Principle, ISP)
開關原則（OCP）
「一個模組(元件)應該開啟擴展之門，
而關閉修改之窗。」此陳述似乎是相互
矛盾的，但它表達出良好元件層級設計
最重要的特性之一。
Liskov替換原則(LSP)
「對基礎類別而言，子類別應該是可替
換的。」
此一設計原則是建議如果一個由基礎類別所衍
生的類別傳遞給替代的元件，使用基礎類別的
元件應該繼續正常地運作。
LSP要求任何源自基礎類別的類別必須要尊重
基礎類別和使用它的元件之間的任何隱含的契
約。
當設計者產生衍生類別(derived class)時，
他們也必須要遵照先決與後決的條件。
相依倒轉原則（DIP）
「依賴抽象化，而不要依賴具體
化。」
抽象化是一個設計不需要很
複雜而可以被擴展的地方。
一個元件越依賴其他的具體
元件(而不是像介面這種的抽
象化)，它將會越困難的被擴
展。
介面隔離原則（ISP）
「由許多客戶所指定的(userspecific)介面要比一般用途的介面
為佳。」
在許多個例(instances)中，多重的
客戶端元件使用由伺服器類別所提
供的操作。
ISP建議設計者應該創造一個專門的
介面以服務每個主要的客戶種類。
元件層級設計的額外套裝原則
在許多情形中，個別的元件或類別被
組織到子系統或套件(package)中所以
Martin建議可應用於元件層級設計的
額外套裝原則：
發行可重複使用等效原則(The Release
Reuse Equivalency Principle, REP)
共同封閉原則(The Common Closure
Principle, CCP)
共同可重複使用原則(The Common Reuse
Principle, CRP)
發行可重複使用等效原則（REP）
「重複使用的顆粒就是所發行的顆粒。」
當類別或元件被設計成可重複使用的時候，
這隱含著建立可重複使用實體的開發者和那
些將使用它的人之間的合約。
開發者承諾建立一套發行控制系統(release
control system)，當使用者很緩慢的升級
到最新的版本時，以支援與維護較舊的實體
版本。
寧願不針對每一個別的類別，當更新的版本
演進時，群聚可重複使用的類別成為套件以
便於管理與控制將是明智的。
共同封閉原則（CCP）
「同屬一個群組的類別一起改變」。
即類別被納入套件中而成為設計的一部
分時，它們應該針對相同的功能或行為
的領域。
當這個領域的某些特性必須要改變時，
則只有在此套件中的類別需要進行修改。
這導致更有效的改變控制與發行管理。
共同可重複使用原則（CRP）
「不在一起被重複使用的類別不應
該群聚在一起」。
當一個或多個在套件中的類別改變時，
套件的版本編號也要改變。
所有其他依賴此改變套件的類別或套件，
現在必須更新到最近的套件版本，並且
進行測試以確保新版本的操作不會有意
外發生。
如果類別不能凝聚地群聚在一起，在套
件中一個與其他類別沒有關係的類別可
能會被改變。
元件層級的設計指導方針
在元件層級設計，Ambler建議下列指導
方針：
元件(Components)
應該建立對元件命名的慣例，這些
元件被指明做為架構模型的一部份，
並且被改進與細化後做為元件層級
模型的一部分。
架構元件的名稱應該從問題領域中
汲取，且應該對所有查看此架構模
型的利益共享者具有意義。
元件層級的設計指導方針
介面(Interfaces)
介面提供有關通訊與協同合作的
重要資訊(可協助我們達成OCP)。
毫無約束的介面表示法易於使元
件圖複雜化。
元件層級的設計指導方針
依附與繼承(Dependencies
and inheritance)
為增進其可讀性，模塑從左到右的依附和
從下到上的繼承(源自類別)是一個很好的
想法。
元件相互依附應該經由介面來表示，而非
藉由元件與元件的依附來表示。
根據OCP的哲學，這將有助於使系統變成
更為可維護的。
凝聚
凝聚是一個元件的「專一性(singlemindedness)」。
在物件導向系統的元件層級設計環
境中，凝聚(cohesion)隱含著一個
只含括屬性與操作的元件或類別，
它緊密地相關到另一個類別或元件
本身。
不同的凝聚型態
機能的(Functional)
層級(Layer)
通訊的(Communicational)
耦合
耦合(coupling)是對類別連接到
另一個類別程度質化的(qualitative)
量測。當類別(和元件)變得更為相互
依賴時，耦合將增加。元件層級設計
的一項重要目標是保持耦合盡可能的
低。
耦合的種類
類別耦合可以用許多種方法呈現其本身，
耦合的種類有下列幾種：
 內容耦合(Content coupling)
 共同耦合(Common coupling)
 控制耦合(Control coupling)
 戳記耦合(Stamp coupling)
 資料耦合(Data coupling)
 常式呼叫耦合(Routine call coupling)
 型態使用耦合(Type use coupling)
 包含或輸入耦合(Inclusion or import coupling)
 外部耦合(External coupling)
物件限制語言
利用UML廣泛多樣性的設計圖，提
供豐富組合的設計模型給設計者。
物件限制語言(Object Constraint
Language, OCL)與UML相互補，它
允許一位軟體工程師使用正規的文
法與語法建構出不同的設計模型元
素(例如，類別與物件、活動、訊
息、介面)明確的敘述。
OCL語言的敘述
最簡單的OCL語言敘述由四個部分所構成：
定義有限制情況的環境(context)，在環境中
其敘述是有效的；
一個表示某些環境特徵的特性(property)(例
如，如果環境是一個類別，則特性可能會是一
個屬性)；
一個操縱或授予(qualify)特性的操作
(operation)(例如，算術、集合導向(setoriented))；
使用來指明條件表示的關鍵字(keyword)(例如：
if, then, else等等)。
OCL中的先決與後決條件
當設計模型建立時，經常有些個例中的
先決(pre-)或後決(post-)條件必須優先
被滿足，以完成由設計所指定的某些動
作。
OCL提供一個有力的工具以指明在正規方
法中的先決與後決條件。
例如，考慮對印刷商店系統的擴充，其中顧
客提供印刷工作的價格上限(upper cost
bound)，並且當其他的印刷工作特性被指明
時，顧客同時提供「馬上要(drop-dead)」
的遞交日期。
如果成本與遞交的估計超過這些上限，則工
作不能提交，且必須要通知顧客。
在OCL中，一組先決與後決的條件可能以下
列的方法指定：
設計傳統的元件
傳統軟體元件的元件層級設計基金會於
1960年代早期形成，並由其和他的同事
一起團結起來工作。
在1960年代後期，該組織提出利用一組
可以形成任何程式的侷限邏輯構造
(constrained logical constructs)。
此構造強調「功能領域的維護」。
此構造是順序、條件和重複。
對結構化程式設計(structured
programming)而言，此三種構造是基本的一
項重要的元件層級設計技術。
此結構化的構造提議對少數可預測
的操作限制軟體的程序設計。
複雜度的度量指出使用結構化的構
造可降低程式的複雜度，並藉此提
高其可閱讀性、可測試性和可維護
性。
使用有限數量的邏輯構造也對人類
瞭解心理學者稱為組塊化
(chunking)的流程有所貢獻。
圖形化的設計記號
活動圖可讓設計師呈現出順序、條件
和重複-所有結構化程式設計的元素 並且是早期稱為流程圖(flowchart)的
繪圖設計表示法(仍然廣泛地使用)的
繼承者。
如同活動圖，流程圖如繪畫般地簡單
方塊(box)用來表示一個處理步驟。
菱形表示邏輯的條件。
箭頭顯示控制的流程。
流程圖三種結構的構造說明
當從一組巢狀迴圈或巢狀條件跳脫
(escape)是有必要時，只是僵化的使
用結構化的構造會引起效率不彰。
沿著跳脫路徑所有邏輯測試所附加的
複雜度將會模糊軟體的控制流向、增
加錯誤的可能性和對可閱讀性與可維
護性產生負面的衝擊。
而程式設計師提供二項選擇：
重新設計程序的表示法，使得控制流向
中巢狀位置的「跳脫分支(escape
branch)」是不需要的；
結構化的構造在控制的方式中被違反；
即設計受到侷限的分支離開巢狀流向。
選項1明顯地是理想的方式，但是選
項2可被調整，而不用違反結構化程
式設計的精神。
表格式的設計記號
在許多軟體應用中，一個模組可能必
須要評估複雜的條件組合，並基於這
些條件挑選適當的動作。
決策表格(decision tables)提供一
組記號，它轉換(translate)動作與
條件(在處理的敘述中被描述)成為表
格的形式。
表格比較不容易被誤解，甚至對於一
個由表格所驅動的演算法可用來做為
機器可讀取的輸入。
決策表格可分成為四個象限(quadrants)
左上的象限包含所有條件的表列。
左下的象限則包含基於條件組合可能的所有
動作表列。
右方的象限形成一個矩陣，以指出條件組合
和特定組合將發生的對應動作。
矩陣的每一行可被解釋為處理規則
(processing rule)。
下列的步驟可應用於發展出決策表格：
列出所有可與特定程序(或模組)結合的行動。
列出所有在程序執行期間的條件(或所做的
決策)。
結合特定的條件組與特定的動作，消除不可
能的組合條件；或發展出每個可能條件的排
列。
藉由指出一組條件會發生什麼動作，以定義
規則。
決策表隔合成的結果
程式設計語言
程式設計語言(program design
language, PDL)也稱為結構化英文
(Structured English)或虛擬碼
(Pseudo code)。
PDL可能很像某種程式設計語言。
PDL和一個真正程式語言之間的差異
在敘述的文字(例如英文)直接地嵌入
在PDL敘述中。
由於使用直接崁入語法(syntactical)
結構內的敘述文字，PDL是不能被編
譯的。
PDL的語法
基本的PDL語法應該包括元件定義、
介面描述、資料宣告、區塊結構化、
條件構造、重複構造和I/O的構造。
PDL可被擴展以包括多重任務
(multitasking)及併行處理、中斷處
理、行程間同步(inter process
synchronization)和許多其他的功能。
使用PDL的應用程式設計應該為設計
語言規定最後的形式。
設計記號的比較
設計記號應該導致一個很容易瞭解
與討論的程序表示法。
記號應該強化「編碼成為(code to)」
的能力，使得程式碼事實上成為一
個自然的設計產物(by-product of
design)。
設計表示法必須能很容易地維護，
使得設計總是可以正確地表示出程
式。
設計記號的問題
活動圖與流程圖的圖表式性質在控
制流向上提供許多設計者所喜愛的
一種觀點。
決策表格精確表格化的內容對表格
所主導的應用程式是一項優良的工
具。
許多沒有在本書中所提及的其他設
計顯示方法，都提供它們自己獨特
的好處。
在最後的分析中，設計工具的選擇
或許比技術上的屬性更緊密地與人
為因素相關。
結語
元件層級設計的動作包含一系
列的任務，而不論表示元件層級設
計所使用的機制為何，其所定義的
資料結構、演算法、介面特性都應
遵照各種以建立完好的設計指導方
針，以在程序的設計演進時協助軟
體工程師避免錯誤發生。
Q＆A