軟體工程第六版 第九章 設計工程

設計工程簡介 設計工程含括一組原則、概念和實務，以

導引高品質系統或產品的發展。 設計原則 ( 在第 5 章中討論 ) 建立置換

(overriding) 的哲學，在所執行的工作中指導設計者。

當應用設計實務機制之前，必須要先瞭解設計概念，並且設計實務本身也導致軟體某些不同的表示法，做為隨後建構活動的指導。

軟體設計宣言 設計是核心的工程活動。 在 1990 年代早期 Mitch Kapor ， Lotus

1-2-3 的創造者，於 Dr. Dobbs 雜誌中發表一篇「軟體設計宣言」。他說：什麼是設計？它是你的一隻腳站在二個世界

中　　科技的世界和人的世界與人的目的　　且你嘗試著將二者合在一起……

設計良好的軟體所具有的特性

羅馬的建築評論家 Vitruvius 的想法：設計良好的建築物就是展現堅固 (firmness) 、實用

(commodity) 和愉悅 (delight) 的那一些。 設計良好的建築物可以用來述說優良的軟體。

堅固：一個程式應該沒有任何的臭蟲 (bug) 約束到它的功能。

實用：一個程式應該適合於它所設計意圖的目的。愉悅：使用程式的經驗應該是很愉悅的一種。這裡我們已

開始軟體設計的理論。

快速瀏覽 它是什麼？　

事實上設計是每位工程師想要做的。它是創造力規則所在的地方　　

顧客需求、商務需要和技術考慮，全部都聚集在產品或系統的規劃中。

設計創造出軟體的表示或模型，但不像分析模型 ( 聚焦在描述所需要的資料、功能和行為 ) ，設計模型提供有關實作系統所必需要的軟體資料結構、架構、介面和元件的細節。

誰完成它？　軟體設計師帶領每個設計任務。

快速瀏覽 它為何重要？　

設計讓軟體工程師模塑所要建構的系統或產品。○ 此模型可以評估其品質，並且在產生程式碼、

導入測試和大量的終端使用者涉入前先行改進。設計是軟體品質建立的地方。

快速瀏覽 步驟為何？　

設計可以用許多不同的方式描繪軟體。○ 系統或產品的架構必須要呈現。○ 連結軟體到終端使用者、軟體到其他系統與裝

置，和軟體對本身構成元件介面的塑模。○ 設計用來建構系統的軟體元件。

這些觀點的每一個都表示一種不同的設計行動，但所有的設計行動必須要遵照一組指導所有軟體設計工作的基本設計觀念。

快速瀏覽 工作產品為何？　

含括架構、介面，元件層級和部署表示的設計模型是軟體設計期間所產生的主要工作產品。

我如何確定我所做的是正確的？　設計模型由軟體團隊評估，以盡力決定它是否有錯誤、不一致性或疏忽；

是否有更好的替代選擇存在；和此模型是否可於執行的侷限、時程和成本內

建立。

設計工程的目的 設計工程的目的是製作一個模型或表示法，以

展現其為堅固、實用和愉悅的。設計者必須要實踐多樣性 (diversification) ，接著收斂

(convergence) 。 Belady陳述：

「多樣性是獲得全部可供選擇的替代方案、設計的原始材料：元件、元件解決方案和知識，全部包含在型錄 (catalog) 、教科書和心中。」一旦資訊發散的集合被組成，設計者必須藉由需求工程 ( 第 7 章 )從全部所需要的定義與分析模型 ( 第 8 章 ) 中挑選元素。當此發生時，替代的選擇會被考慮或剔除，並且設計工程師收斂於「一個特定的元件組態，並因此產生最終的產品。 」

設計工程的發散與收斂 發散與收斂需要直覺與判斷。

這些的品質是基於建構相似實體的經驗、指導模型演進方式的一組原則或經驗法則 (heuristics) 、一組判斷品質的標準和一個最終導致最後設計呈現的反覆流程方法。

當新的方法、更好的分析和更廣泛地瞭解演進時，電腦軟體的設計工程將不斷地改變。

9.1 軟體工程環境中的設計 軟體設計位在軟體工程技術的核心，並且

它不管其使用的任何軟體流程模型而被應用。

一旦軟體需求被分析與塑模後就開始，軟體設計是塑模活動中最後的軟體工程活動，並設定建構的階段 ( 產生程式碼與測試 ) 。

「軟體工程最普通的奇蹟是由分析到設計、由設計到編碼的轉換。」 Richard Due

分析模型轉換成為設計規格 分析模型的每個元素對所必要的完整設計規格提供創造四

個設計模型所需要的資訊。 在軟體設計期間的資訊流向 (information flow) 說明如圖

9.1 。藉由以情境為基礎、以類別為基礎、以流向為導向和行為

元素所顯露出的分析模型提供給設計任務。 使用設計記號與設計方法，產生資料 /類別的設計、架構的

設計、介面設計和元件設計。 資料 /類別設計轉換分析類別 (analysis class) 模型成為設

計類別的實現 (realizations) ，和需要實作軟體所必要的資料結構。

由 CRC索引卡片所定義的類別與關係、由類別所描述的詳細資料內容和其他提供資料設計活動基礎的記號。

部分的類別設計可能發生在與軟體架構設計相連接的地方。 當每個軟體元件被設計時，更多詳述的類別設計將會發生。

圖 9.1 轉換分析模型成為設計模型

架構的設計 架構的設計定義軟體主要結構元素間的關係、可以使用來達成由系統所定義需求的結構型態與設計模式，和影響架構實作方法的侷限。

架構設計表示法 - 以電腦為基礎的系統框架 - 可由系統規格、分析模型和定義於分析模型中的子系統互動。

介面設計 介面設計描述軟體如何與相互操作的系統

與使用它的人之間的溝通。 一個介面隱含著一個資訊的流向 (例如，

資料及 / 或控制 ) 與特定的行為型態。使用情境與行為模型提供許多介面設計所必

要的資訊。

元件層級的設計 元件層級的設計轉換軟體架構的結構化元素成為軟體元件的程序描述。從以類別為基礎的模型、流向模型和行為模

型中所獲得的資訊，可做為元件設計的基礎。 設計期間我們所決定的最終將會影響軟體

建構的成功，而同樣重要的是軟體能容易的維護。

為什麼軟體設計如此重要？ 軟體設計的重要性可以用一個字來說明 - 品質。

設計是軟體工程中品質養育的所在。設計提供我們可以評估軟體品質的表示。設計是我們可以準確地將顧客的需求轉換成為完成的

軟體產品或系統的唯一方法。軟體設計作為所有的軟體工程和接續的軟體支援活動

的基礎。 當在時間不夠且已經花費許多經費，若沒有設

計，我們就是在冒險建立一個不穩定的系統　　當小的改變產生時它將會失敗；它可能難以測試；它

的品質直到軟體流程的晚期之前都無法被評估。

9.2 設計流程與設計品質 軟體設計是一個反覆的流程，使需求得以轉化

成為所建構軟體的「藍圖 (blueprint) 」。藍圖描述軟體全部的觀點。

○ 設計是高度抽象層級的表示一個可對特定系統目標和更為詳細的資料、功能與行為需求直接追蹤的層級。

當設計反覆發生時，隨後的改進導致在更低抽象層級的設計表示。○ 這些仍能被追溯到需求，但其間的連接則更難以捉摸。

評估良好設計的指導 整個設計流程中，演進的設計品質與一系列的正規技術檢視

或將於設計排練時一起被評估。 McGlaughlin 建議三種特性，它們可以做為評估良好設計的指

導： 設計必須實作所有包含於分析模型中的明顯需求，並且必須要

適應顧客想要的所有隱含的需求。對那些產生程式碼和那些測試與隨後支援軟體的人，設計必須

是可讀的、可瞭解的指導。 設計應該從實作的觀點針對資料、功能和行為的領域，提供一張軟體的完整圖像。

這些特性的每一個實際上都是設計流程的目標。但如何達成這些目標？

撰寫一段聰明的程式碼是一回事；設計能支援持久的商業運作則是一件相當不同的事。」 C. Ferguson

品質指導方針 (Quality guidelines)

為評估設計所表示的品質，我們必須要建立良好設計的技術準則。先說明下列的指導方針：一個設計應該展現如下的架構：

○ 使用已認可的架構型態或模式，○ 由展現良好設計特性 ( 將於本章稍後討論 ) 的元件所組成，

和○ 能以演進的形式 1 實作，藉此促進實作與測試。

一個設計應該是模組化的；即軟體應該合乎邏輯的分割而成為元素或子系統。

一個設計應該含括資料、結構、介面和元件等明顯的表示。

一個設計應該引導出資料結構，其適合於所要實作的類別，並從可辨識的資料模式中選取出。

品質指導方針 (Quality guidelines)

一個設計應該引導出展現獨立功能特性的元件。一個設計應該引導出介面，它降低元件與外部環境間相連結的複雜度。

一個設計應該得自於使用可重複的方法，它藉由軟體需求分析期間獲得的資訊所驅動。

一個設計應該使用一種能有效溝通其意義的記號來表示。

這些設計指導方針的達成不是偶然的。設計工程鼓勵經由基本設計原則的應用、系統化的方法

學和徹底地檢視所構成的良好設計。

評估設計品質 - 正規的技術檢視 設計是重要的，因為它允許一個軟體團隊在實作前評估軟

體的品質 每當錯誤、疏忽或不一致時，可以很容易且便宜地修正。

但是我們如何在設計期間評估品質呢？軟體不能被測試，因為沒有可執行的軟體做為測試。那該做些什麼呢？

在設計期間，品質是由導入一系列的正規技術檢視 (formal technical reviews, FTRs) 來評估。 FTR 是一個由軟體團隊成員所主導的會議。通常視所需檢視的設計資訊範圍，由二至四人參與討論。 每個人扮演一個角色：檢視領導者 (review leader) 計畫會議、設定會議程序，然後進行會議；記錄者 (recorder) 做筆記以避免任何的遺漏；生產者 (producer) 是工作產品(例如，某個軟體元件的設計 )正被檢視的人。

品質屬性 (Quality attributes) 惠普公司 (Hewlett-Packard)[GRA87] 發

展出一組軟體品質屬性，並以字母首字縮寫成 FURPS功能性 (functionality)可使用性 (usability)可靠性 (reliability)效能 (performance)可支援性 (supportability) 。

FURPS 品質屬性 FURPS 品質屬性代表所有軟體設計的一個目標：

功能性○ 藉由評估其性能組 (feature set) 與程式的能力、所遞交

功能的主要部分和整體系統的安全性而進行評估。可使用性

○ 藉由考慮人為因素 (human factors)( 第 12 章 ) 、整體美學、一致性和文件編寫來評估。

可靠性○ 藉由測量故障的頻率與嚴重程度、輸出結果的準確度、平均失敗時間 (MTTF) 、失敗恢復能力和程式的可預測性來評估。

FURPS 品質屬性效能

○ 是藉由處理速度、回應時間、資源消耗、貫通率 (throughput) 和效率來測量。

可支援性○ 結合擴展程式的能力 (擴充性 ) 、適應性、可服務性 (serviceability) 　　這三種屬性表示一種更為普通的術語 - 可維護性

(maintainability) 　　○ 可測試性、相容性、組態 (configuration)

軟體組態元素的組織與控制能力、系統安裝的容易性，和使問題可被局部化的容易性。

設計的一般任務組 檢查資訊領域模型，並為資料物件與其屬

性設計適當的資料結構。 使用分析模型，選擇一個適合軟體架構的

型態 ( 模式 ) 。 切割分析模型成為設計子系統，並配置這

些子系統到結構中。確定每個子系統在功能上是凝聚的 (cohesive) 。設計子系統介面。配置分析類別或功能到每個子系統。

設計的一般任務組 創造一組設計類別或元件。

轉換每個分析類別描述成為設計類別。依照設計標準檢查每個設計類別，並考慮繼承議題。

定義結合每個設計類別的方法與訊息。為設計類別或子系統評估與選擇設計模式。檢視設計類別，並於有必要時修訂。

設計的一般任務組 設計任何外部系統或裝置所需要的介面。 設計使用者介面。

檢視任務分析的結果。基於使用者情境指定動作的順序。創造介面的行為模型。定義介面物件與控制機制。檢視介面設計，並於有必要時修訂。

設計的一般任務組 導入元件層級的設計。

在相對低的抽象化層級上指明所有的演算法。改善每個元件的介面。定義元件層級的資料結構。檢視每個元件並修正所有發現的錯誤。

發展部署模型。

9.3 設計概念 一組基本的軟體設計概念已經在軟體工程

的歷史上演進。雖然對每項概念有興趣的程度近年來有些變化，但每個都歷經時間的考驗。

它們提供軟體設計者一項基礎，因而更為精細的方法可以被應用。

M. A. Jackson曾經說道：「 [ 軟體工程師 ]智慧的開端是就分辨出拿程式去執行與拿對的程式之間的差異」。基礎的軟體設計概念提供「將它做對」所需要的框架。

9.3.1 抽象化 當我們對任何問題考慮模組化的解決方案時，會造成許多抽象化 (abstraction) 的層級。在抽象化的最高層級，解決方案是使用問題環境的語

言以大範圍的角度陳述。在抽象化較低的層級，解決方案提供較為詳細的描述。

「抽象化是我們人類對付複雜的基本方法之一。」 Grady Booch

程序與資料的抽象化 當我們移動經過不同的抽象化層級，我們著手創造程序的 (procedural) 與資料的抽象化。程序的抽象化 (procedural abstraction)參考具特定與限制功能的指令順序。○ 程序抽象化的名稱隱含著這些功能，但是特定的細

節還是被抑制的。○ 程序抽象化的例子將會如一扇門的開啟 (open) 這

個字。開啟隱含著程序步驟很長的順序 (例如：走到門前、伸出

並握住門把、扭轉門把並拉開門、跨出門等 ) 。

程序與資料的抽象化資料抽象化 (data abstraction) 是一個被稱為

描述某個資料物件的資料集合。○ 在開啟 (open) 這個程序抽象的環境中，我們可

以定義稱為 door ( 門 ) 的抽象化資料。如同其他的資料物件， door 的資料抽象化將包括描述門的一組屬性 (例如： door type(門的型態 ) 、 swing direction(擺動的方向 ) 、 opening mechanism( 開啟的機制 ) 、 weight( 重量 ) 、 dimensions(尺寸 )) 。

○ 它遵循開啟 (open) 這個程序抽象化所要利用而包含在門 (door) 這個資料抽象化中的屬性。

9.3.2 架構 軟體架構 (software architecture) 約略提到「軟

體的整體架構，和其內結構所提供系統概念整合的方式。」

在最簡單的形式中，架構是結構或程式元件( 模組 ) 的組織、這些元件互動的方法和由元件所使用的資料結構。元件可被歸納以表示主要的系統元素和它們的互動。

「軟體架構是發展工作的產品，它給投資於品質、時程和成本最高的回饋報酬。」 Len Bass等人

軟體設計的目標 軟體設計的一個目標是獲得一個系統架構

的演繹 (rendering) 。此演繹提供一個框架，並將更為詳細的設計

活動導入此框架中。 一組架構的模式讓軟體工程師重複使用設

計層級的概念。

架構設計的模型 架構設計可以使用許多不同模型中的一種或多

種來表示。結構模型 (structural models) 表示一個組織程式元件集合

的架構。框架模型 (framework models)藉由嘗試在所碰到類似型態

的應用程式中，辨識可重複的架構設計框架，以增進設計抽象化的程度。

動態模型 (dynamic models)針對程式架構的行為面向，指出結構或系統組態可能如何改變作為外部事件的功能。

處理模型 (process models) 聚焦於系統所必須調適的商業或系統流程的設計。

功能模型 (functional models) 可使用於表示系統功能的階層。

9.3.3 模式 Brad Appleton 以下列的方法定義設計模式 (design

pattern) ： 「模式被稱為具有洞察力的珍品，它對於某個特定環境中

不斷發生的問題傳達已經證明過的解決方案的本質[APP98] 。」

設計模式描述設計結構，以解決特定環境中的特定設計問題，和對模式應用與使用的方法中帶來衝擊的「支配力」。

「每個模式描述一個在我們的環境中一再地發生的問題，然後描述對此問題的解決方案核心，用這種方式你可以使用此一解決方案超過百萬次以上，而不必用相同的方法做兩次。」 Christopher Alexander

設計模式的意圖

每個設計模式的意圖是提供描述，使設計者能決定：模式是否可應用於目前的工作模式是否能重複使用 (因此節省設計時間 )模式是否可以做為發展類似、但功能上或結構

上不同的模式指導。

9.3.4 模組性 軟體架構與設計模式使模組性 (modularity)更為

具體化；即軟體被區分為個別的命名與可定址的元件，有時稱為模組 (modules) ，以整合滿足問題的需求。

「模組性是軟體的單一屬性，以使程式在理智上是可管理的。單體的 (monolithic) 軟體 (即一個大程式是由單一個模

組所組成 )無法由軟體工程師輕易地掌握。○ 控制路徑的數量、參照的跨度 (span) 、變數的數量和整體的複雜度將連瞭解都成為不可能。

分割與克服 (divide and conquer) 當你將複雜的問題分割成為可管理的部分時，問題就比較容易地解決。這對模組性與軟體有重要的意涵。

可能的結論是，如果我們沒有明確地細分軟體，發展所需的投入將會變成可忽略的少！不幸的，其他的力量因此進入，造成此一無效的 (悲傷地 ) 結果。

模組數與投入曲線 發展個別的軟體模組的投入 ( 成本 )確實會因模組總數的增加而減少。給定相同的需求集合，更多的模組意味著較小的個別規模。

當模組的數目成長時，與整合模組結合的投入 ( 成本 ) 也會成長。

這些特性導出總成本或投入曲線，如圖9.2 所示。

圖 9.2 模組性與軟體成本

最佳模組數 有一數目為 M 的模組將會有最低的發展

成本，但是我們沒有必要保證預測出 M 。當考慮模組性時，如圖 9.2 所顯示的曲線確

實提供有用的指導。我們應該模組化，但是應該小心地處於 M 的附近。○ 模組性不足 (undermodularity) 或過度模組性

(overmodularity) 都應該避免。 我們如何知道在 M 的附近呢？ 我們應該如何以模組來發展軟體呢？

模組化的好處 模組化一個設計 ( 並做為結果的程式 ) 的

好處發展可以更容易地計畫；軟體增量可以被定義與遞交；改變可以更容易地調適；測試與除錯可更有效率的導入，並且長期的維護將被導入而沒有嚴重的副作用。

9.3.5 資訊隱藏 模組性的概念引導每位軟體設計者面對一

個基本問題：我們如何分解軟體的解決方案而獲得最佳模

組的集合？ 資訊隱藏 (information hiding) 的原則建議模組是「藉由設計決定對所有其他都是隱匿的 ( 每一個 )而描繪出其特性」。模組應該被指明與設計，以使包含在某個模

組裡的資訊 (演算法與資料 )對其他不需要此資訊的模組是難以存取的。

資訊隱藏的益處 隱藏意味著有效的模組性可藉由定義一組獨立

模組，它與另一個只有資訊需求的模組相互通訊，以達成軟體的功能。抽象化協助定義組成軟體程序的 ( 或資訊的 ) 實體。隱藏模組內的程序細節和由模組所使用的任何局部資

料結構，定義並實施存取的限制。 當在測試或稍後的期間中必須要修改時，為模

組化系統而使用資訊隱藏做為設計的準則，將可以提供最大的利益。因為大部份的資料與程序對軟體的其他部分都是隱藏

的，所以在修改期間因為漫不經心所引起的錯誤，比較沒有可能會漫延到軟體其他的地方。

9.3.6 功能獨立 功能獨立 (functional independence) 的概念是

模組化、抽象概念和資訊隱藏的直接結果。功能獨立是藉由「專一的 (single-minded) 」功能和

「厭惡 (aversion) 」與其他的模組極度的互動所發展出的模組而達成。

我們要設計軟體以使每個模組針對某個特定需求的子功能 (subfunction) ，並且由程式結構的其他部分，有個可用來觀看的簡單介面。

○ 質問獨立性為什麼那麼重要是很公平的。

有效模組性與功能獨立 具有有效模組性的軟體 (即獨立的模組 )因其功能可被劃分，且介面也被簡化 ( 當由團隊導入發展時，要考慮其分歧 ) ，因此較為容易發展。

獨立模組是比較容易維護 ( 與測試 ) ，因為由設計或程式碼修改所造成的次要影響是有限的、錯誤傳播也會降低，且可重複使用的模組成為可能。

評估獨立性的性質 功能獨立是良好設計的關鍵，而設計是軟

體品質的關鍵。 獨立性使用兩個質性的 (qualitative)標準

評估：凝聚 (cohesion) 與耦合 (coupling) 。凝聚是一個模組相對功能強度的象徵。耦合是在模組之間相對的相互依賴

(interdependence) 的象徵。

凝聚與耦合 凝聚是資訊隱藏概念的自然擴展。

一個凝聚的模組實行單一任務，對程式的其他部分只需要與其他的元件有很少的互動。

一個凝聚的模組應該 ( 理想上 )只做一件事情。 耦合是在軟體結構中模組之間相互連接的指示。

耦合依賴模組之間的介面複雜度、設計給模組的進入或參照點，和跨越介面所傳遞的資料。

在軟體設計中，我們努力將可能的耦合降到最低。在軟體模組間簡單的連接會較為容易瞭解，並減少易

於造成某個位置的錯誤發生與傳遍整個系統的「漣波效應 (ripple effect) 」。

9.3.7 細化的改進 最初由 Niklaus Wirth 所提議的逐步改進是由上往下的 (top-down) 設計策略。程式是藉由保留地改善程序細節程度而發展。階層是藉由逐步的形式分解宏觀的

(macroscopic) 功能敘述 ( 程序的抽象化 ) ，直到達成程式語言的敘述。

改進

改進實際上是一個細化 (elaboration) 的流程。

我們以一個定義在高度抽象化的功能敘述開始 ( 或資料的描述 ) 。敘述在概念上是描述功能或資訊，但不提供關

於功能的內部工作或資料內部結構的資訊。 改進造成設計者在原來的敘述上進行細化，

且當每個連續的改進 ( 細化 )時，將提供越來越多的細節。

抽象化與改進

抽象化與改進是互補的概念。抽象化讓一位設計者指定程序與資料，然而卻抑制低層級的細節。

當設計進展時，改進協助設計者揭露出低層級的細節。

當設計演進時，此兩個概念輔助設計者創造一個完整的設計模型。

「我沒失敗。我只是找到 10,000 種不能工作的方法」。 Thomas Edison

9.3.8 　重構 重構 (refactoring) 是一項重要的設計活動，它簡化元件設計

( 或程式碼 ) ，但沒有改變它的功能或行為的重組技術。 Fowler 以下列的方式定義重構：

「重構是改變軟體系統的流程，用這種方法，它不會改變程式碼的外部行為 [ 設計 ] ，但仍然改善它內部的結構。」

當軟體重構時，檢查現存設計的冗餘性 (redundancy) 、沒用的設計元件、沒有效率或沒有必要的演算法、不良的結構或不適當的資料結構，或任何仍能修改成更好設計的其他設計上錯誤。例如，第一次的設計反覆可能產生一個展現低凝聚性的元件

(即它執行三個功能，但對另一個只有有限的關係 ) 。 設計者可能決定元件應該被重構成為三個個別的元件，每個都

展現出高度的凝聚性。 重構的結果使軟體更容易整合、更容易測試和更容易維護。

9.3.9 　設計類別 分析模型定義一組完整的分析類別。

這些類別的每一個描述問題領域中的某些元素，聚焦於使用者或顧客可看得見的問題面向(aspects) 。

分析類別的抽象化層級相對地是很高的。 當設計模型演進時，軟體團隊必須要定義一

組設計類別 (design classes) ，以便：藉由提供設計的細節以改進分析類別，使類別能被實作，

創造一組新的設計類別，以實作軟體基礎架構，支援商務的解決方案。

設計類別的五種不同型態

五種不同設計類別的型態建議如下，每一種都表示設計架構中不同的層級：使用者介面類別 (User interface classes) 　

○ 定義人 -電腦互動 (human-computer interaction, HCI)所必須有的抽象概念。許多情形下， HCI 發生在設計類別所隱喻 (metaphor) 的環境中 (例如：支票簿、訂貨單、傳真機 ) ，且介面的設計類別可能是所隱喻元件的可視呈現。

商務領域類別 (Business domain classes) 　○ 經常是先前所定義分析類別的改進。類別確認某些商

務領域所必須實作的元素屬性與服務 ( 方法 ) 。

設計類別的五種不同型態

處理類別 (Process classes) 　○ 實作較低層級的商務抽象概念，必須能完全管理商務

領域的類別。持續類別 (Persistent classes) 　

○ 表示資料儲存 (例如資料庫 ) ，它將在軟體執行之後還持續著。

系統類別 (System classes) 　○ 實作軟體管理與控制功能，使系統能在它內部的計算環境與外部的世界進行操作與通訊。

發展設計類別的屬性與操作

當設計模型演進時，軟體團隊必須為每個設計類別發展一組完整的屬性與操作。當每個分析類別轉換成為設計的表示時，抽象化

的層級會降低。 ○ 分析類別表示物件 ( 和應用於結合它們的服務 ) 。○ 設計類別顯著地呈現更為詳盡的技術細節，以為實作

的指導。

完型狀態設計類別的特性

Arlow 與 Neustadt 建議每個被檢視的設計類別要確保它是「完型的 (well-formed) 」。

定義四個完型狀態設計類別的特性：完整與充分 (Complete and sufficient)基本 (Primitiveness)高度凝聚 (High cohesion)低度耦合 (Low coupling)

完整與充分 (Complete and sufficient) 一個設計類別應該完整封裝所有能合理期望存在於類別中的屬性與方法 (基於類別名稱有知識的解釋者 ) 。例如，唯有包含所有能適度地與影像場景創造所

結合的屬性與方法時，定義於影像編輯軟體的Scene(場景 )類別才會完整。

充分性確認設計類別只包含那些足夠達成類別的企圖，不多也不少。

基本 (Primitiveness)

結合設計類別的方法應該聚焦於為類別完成一項服務。一旦服務已經以方法實作後，類別不應該提供另

一種方法來完成相同的事情。○ 例如，影像編輯軟體的 VideoClip類別可能有 start-

point(啟始點 ) 與 end-point( 結束點 ) 的屬性，以指示剪輯的開始與結束 (注意載入系統內的原始影像可能比所要使用的裁剪影像 (clip)還要長 ) 。

○ setStartPoint() 與 setEndPoint() 的方法提供唯一建立啟始與結束點的方法。

高度凝聚 (High cohesion)

凝聚的設計類別有一個小的、聚焦於責任集合和專一地 (single-mindedly) 應用屬性與方法，以實行那些責任。例如，影像編輯軟體中的 VideoClip類別或許包

含一組編輯裁剪影像的方法。一旦每個方法都單獨地聚焦於裁剪影像的屬性上，

就維持住凝聚。

低度耦合 (Low coupling)

在設計模型中，設計類別與其他的類別協同合作是必需的。協同合作應該保持在一個最低可接受的程度。

○ 如果一個設計模型高度地耦合 ( 所有的設計類別與其他所有的設計類別協同合作 ) ，系統將難以實作、測試和長時間的維護。

○ 在子系統中的設計類別應該只有其他子系統中類別的有限知識。這種限制，稱為 Demeter定律，它建議一個方法應該只傳遞訊息給鄰近類別的方法。

圖 9.3 平面圖的設計類別與類別的合成匯聚

9.4 設計模型 設計模型 (design model) 可以兩種不同的維度

(dimension)檢視，如圖 9.4 所示。處理維度 (process dimension) 指出當設計任務做為軟

體流程的一部分而被執行時，設計模型的演進。抽象維度 (abstraction dimension) 表示每個分析模型

的元件被轉換成設計等同物 (equivalent) 後反覆改進的詳細程度。

參考圖 9.4 ，虛線表示分析與設計模型的分界。某些情況中，分析與設計模型間清楚的區別是有可能

的。而其他的情況中，分析模型逐漸地混合融入到設計中，並且其清楚的區別較為不明顯的。

設計模型的元素 設計模型的元素使用許多和 UML 使用於分析模

型相同的圖表。其間的差異只是這些圖表被改進與細化成為設計的一

部分；更多的實作 - 提供特定的細節、架構的結構與型態、架構中所駐留的元件，和元件與外部世界的介面，所有的都被強調。

沿著水平軸所標記的模型元素並不總是以順序的形式發展。在大部分的情形中，初步的架構設計設定階段，並經常被以平行進行的介面設計與元件層級設計所遵循。

部署模型通常都會延遲到設計已被完全發展之後。

圖 9.4 設計模型的維度

9.4.1 　資料設計元素 資料設計 (data design)( 有時稱為資料架

構 (data architecting)) 創造以高度抽象化( 顧客 / 使用者的意見資料 ) 所表示的資料或資訊模型。此一資料模型逐漸改進成可由以電腦為基礎

的系統所處理的特定的實作 (implementation-specific) 表示。

在許多軟體應用程式中，資料的架構對於必須處理它的軟體架構將具有極深的影響。

資料的結構 資料的結構一直都是軟體設計的重要部分。

在程式元件層級，資料結構的設計和必須要操作它們而結合的演算法對高品質應用程式的產生是不可或缺的。

在應用程式層級，資料模型 (獲得自需求工程的一部分 )轉變成為資料庫是達成系統商務目標的關鍵。

在商務層級，資訊的集合儲存於不同的資料庫中，並重組成為「資料倉儲 (data warehouse) 」，讓資料探勘 (data mining) 或知識發現對業務本身的成功產生衝擊。

9.4.2 架構設計元素 軟體的架構設計 (architectural design)等

同於房屋的平面圖。平面圖描述房間、它們的大小、形狀、與其

他房間的關係，和允許進入或走出房間的門與窗戶等的整體規劃。

平面圖給我們房子的整體視野。架構設計元素給我們軟體的整體視野。

「你可以在草圖上使用橡皮擦，或是在建築工地上使用大錘」。 Frank Lloyd Wright

架構模型的來源 架構模型獲自三個來源：

有關於所要建造軟體應用領域的資訊；特定的分析模型元素，如資料流向圖或分析類別，它們對手上問題的關係與協同合作，和

架構模式 ( 第 9.5 節 ) 與型態 ( 第 10 章 ) 的有效性。

9.4.3 　介面設計元素 軟體的介面設計等同於對房子的門、窗戶和屋外設施的一組詳細的設計圖 ( 與規格 ) 。這些設計圖描繪門與窗戶的大小與形狀、它們操作使

用的方式，和進入房子中各種設施的連接 (例如，水、電、瓦斯、電話 ) ，和在平面圖上描繪它們分配到每個房間的方式。○ 它們說明門鈴設置的位置、有訪客來訪時是否要使用對講機通知，和安全系統如何安裝。

○ 基本上，門、窗戶和外部設施的詳細設計圖 ( 和規格 )說明事物與資訊如何流入與流出房子與做為平面圖一部分的房間內。

軟體介面設計的元素說明資訊如何流入與流出系統，和它們如何在定義成為架構一部分的元件間通訊。

介面設計的重要元素 介面設計有三個重要的元素：

使用者介面 (UI)；對其他系統、裝置、網路或其他資訊的生產

者與或消費者的外部介面；和各種不同設計元件間的內部介面。

這些介面設計元素讓軟體進行外部與內部的通訊，並在軟體架構的元件之間協同合作。

UI 設計 UI 設計是一項主要的軟體工程行動。

UI 的設計結合美學的元素 (例如，編排 (layout) 、色彩、圖形、互動機制 ) 、人因工程學(ergonomic) 的元素 (例如，資訊配置與安置、隱喻 (metaphor) 、 UI 導引 ) 和技術的元素 (例如， UI 模式、可重複使用的元件 ) 。

UI 在整個應用程式架構中是一個獨特的子系統。

外部介面設計

外部介面的設計需要有關於資訊傳送或接收實質定義的資訊。在每種情形中，此種資訊應該在需求工程 ( 第 7

章 ) 期間蒐集，並且一旦介面設計開始時要驗證。

外部介面的設計應該結合錯誤檢查與 ( 有需要時 ) 適當的安全性能。

內部介面的設計

內部介面的設計與元件層級的設計 ( 第 11章 ) 是非常緊密合作的。分析類別的設計實現表示所有的操作和不同類別的操作之間通訊與協同合作所需要的訊息傳送方案。

每個訊息必須被設計以適應必要資訊的轉換，和操作上已經要求的特定功能需求。

介面的塑模 在某些情況中，介面的塑模在許多的方法

上都與類別相同。 UML 以下列的方法定義介面 ：

「介面是一個對外界可見的 [公開的 ]類別、元件，或其他不具有內部結構規格的分類器(classifier)(包括子系統 ) 的指示器 (specifier) 。」

介面是描述一組操作，它描述類別某些部分的行為，並對這些操作提供存取。

9.4.4 　元件層級的設計元件 對於軟體元件層級的設計等同於一組對房屋中每個房間的詳細設計圖 ( 和規格 ) 。此設計圖描述每個房間的配線與管線、電源插座和開關、龍頭、水槽、淋浴間、浴盆、排水管、櫥櫃和壁櫥的位置。

它們也描述所使用的地板、裝飾條的運用，和每個房間的相關細節。

軟體元件層級的設計軟體元件層級的設計完整地描述每個軟體元

件內部的細節。元件層級的設計為所有區域的資料物件，和

發生在一個元件與允許存取所有元件操作 ( 行為 ) 介面中所有處理的演算細節定義資料結構。

元件的表示 在物件導向軟體工程的環境中，一個元件

表示成如圖 9.6 所顯示的 UML 圖形。圖中呈現一個稱為 SensorManagement(安

全家安全功能的一部分 ) 的元件。一條虛線的箭頭連結此元件到一個指定給它稱為 Sensor 的類別。

SensorManagement 元件實行結合安全家感測器的所有功能，包括監測與組態。

圖 9.6 SensorManagement 的 UML 元件圖

元件設計的抽象程度 元件的設計細節可以在許多不同的抽象程度上塑模。活動圖可用來表示處理的邏輯。對於元件詳細的程序流程可以使用虛擬碼

(pseudocode)( 將於第 11 章所描述的一種類似程式語言的表示法 ) 或某些圖表形式 (例如，活動圖或流程圖 ) 。

9.4.5 部署層級的設計元件 部署層級的設計元件指出軟體的功能性與子系統將如何配置於支援軟體的實際計算環境中。例如，安全家產品的元素被組態以在三種主

要的計算環境中運作 - 家用的 PC 、安全家控制面板，和裝置於 CPI公司的伺服器 ( 提供以網際網路存取的系統 ) 。

9.5 以模式為基礎的軟體設計 在任何領域中最佳的設計者都有一種不可思議的能力看出模式，具以描繪問題的特徵和可被結合以創造解決方案所相對應的模式。貫穿整個設計流程，軟體工程師應該找尋每個重複使用現有的設計模式 (若能符合設計需要時 ) 的機會，而不要創造出新的。

9.5.1 描述設計模式

成熟的工程紀律利用數以千計的設計模式。例如，一位機械工程師使用一種以兩個步驟、栓槽軸 (keyed shaft) 做為設計模式。在模式中繼承屬性 (軸的直徑、栓槽的規模等 )與操作 (例如，轉動軸、連接軸 ) 。一位電機工程師使用積體電路 ( 一個極度複雜的設計模式 ) 解決某個新問題特有的元素。設計模式可以使用如邊框所顯示的樣版來描述[MAI03] 。

設計模式樣版 模式名稱　　

除表示名稱之外，並簡短的描述模式的本質。 意圖

描述模式和它做些什麼。 已知同樣的

列出此模式的任何同類模式。 動機　　

提供問題的範例。 適用性　　

提及模式可應用的特定設計情況。

設計模式樣版 結構　　

描述實作模式所必要的類別。 參與者　　

描述實作模式所必要類別的責任。 協同合作　　

描述參與者如何協同合作以實現他們的責任。 影響　　

描述影響模式的「設計驅力 (design-force) 」，和模式實作時所必須考慮可能的權衡。

相關的模式　　交互參照的設計模式。

設計驅力 設計模式的描述也可以考慮成一組設計

力度。 設計驅力 (design forces) 描述此模式被

應用時，結合軟體的非功能性需求 (例如，維護性的容易度、可攜性 ) 。驅力定義設計被實作時，可能會限制這個方

法的侷限。本質上，設計驅力描述使設計模式可以應用

所必須存在的環境與條件。

模式的特性

模式的特性 (類別、責任與協同合作 )指出設計的屬性，它可被調整以讓模式能夠適應各種的問題。

這些屬性表示可被搜尋 (例如，經由資料庫 ) 到的設計特性，以至於能發現適合的模式。

結合設計模式使用的指導以提供設計決定分歧 (ramification) 的指示。

設計模式的命名

設計模式的名稱應該小心地選擇。軟體重複使用的一個關鍵技術問題是當有數百或數以千計的候選模式存在，而沒有能力找到現存可重複使用的模式。

藉由有意義的模式名稱可以協助搜尋「對的」模式。

9.5.2 　設計的使用模式 設計模式能遍及於整個軟體設計中使用。 一旦分析模型 ( 第 8 章 ) 已經發展出，設

計者可以檢查其所要解決問題的細節表示，和由問題所強加的侷限。

設計模式的類型 問題的描述在各種不同的抽象化層級中被檢查，

以決定是否有符合下列一個或多個類型的設計模式：架構模式　

○ 這些模式定義軟體的整體結構、指出子系統與軟體元件之間的關係，和定義指明元素之間 (類別、套裝、元件、子系統 ) 關係的架構規則。

設計模式　○ 這些模式針對設計的特定元素，如解決某些設計問題

的元件匯聚 (aggregation) 、元件之間的關係，或影響元件對元件通訊的機制。

慣用語 (Idioms) 　○ 有時稱為編碼模式 (coding patterns) ，這些語言特定

的 (language-specific) 模式通常實作一個元件的演算元素、特定的介面協定，或元件之間通訊的機制。

9.5.3 框架 在某些情況中，必須提供稱為框架 (framework) 的

實作特定的 (implementation-specific)骨架基礎建設 (skeletal infrastructure) 的設計工作。設計者可能選擇一個「可重複使用的迷你架構 (reusable

mini-architecture) ，對一系列的軟體抽象概念提供一般的(generic) 結構與行為，連同環境……它詳細指出它們的協同合作和所給定領域內的使用。

框架不是一個架構的模式，但更確切的說是個「插入點 (plug points) 」集合的骨架 ( 也稱為掛鉤(hooks) 與插槽 (slots)) ，使得它對特定的問題領域得以適用。插入點讓設計者整合骨架中問題的特定類別或功能性。

在物件導向的環境中，框架是合作類別的集合。

框架的運用 本質上，框架的設計者將會爭辯某個可重複使用的迷你架構，是可以應用於所有在應用的限制領域中發展的軟體。要最為有效，框架應用時無須改變。

○ 可以增加附加的設計元素，但只經由插入點以允許設計者可長出框架的骨架。