模型化軟體系統的架構
若要協助確保您的軟體系統或應用程式符合使用者的需求，您可以在 Visual Studio Ultimate 中建立模型，當做軟體系統或應用程式之整體結構和行為描述的一部分。 您也可以使用模型來描述整個設計所使用的模式。 這些模型可協助您了解現有架構、討論變更，並清楚地傳達您的意圖。
模型的目的是要減少自然語言描述中所發生的模稜兩可，並且協助您和同事視覺化設計以及討論替代設計。 模型應該搭配其他文件或討論一起使用。 模型本身無法代表完整的架構規格。
.gif "注意事項") 注意事項 |
|---|
在本主題中，「 系統 」表示您正在開發的軟體。 它可能是許多軟體和硬體元件的大型集合、單一應用程式，或應用程式的一部分。 |
系統的架構可以分成兩個區域：
高階設計。 這會描述主要元件以及它們如何彼此互動以實現每個需求。 如果系統很龐大，每個元件可能會有自己的高階設計，其中顯示它如何由較小的元件組成。
設計模式和整個元件設計中使用的慣例。 模式會描述達成程式設計目標的特定方法。 只要在整個設計中使用相同的模式，您的小組就可以降低進行變更和開發新的軟體的成本。
高階設計
高階設計會描述您系統的主要元件以及它們如何彼此互動以達成設計的目標。 下列清單中的活動會包含在高階設計的開發作業中，但是不一定會按照特定順序。
如果您正在更新現有的程式碼，可能會從描述主要元件開始。 請確定您了解對使用者需求所做的任何變更，然後再加入或修改元件之間的互動。 如果您正在開發新的系統，請從了解使用者需求的主要功能開始。 然後，您可以探索主要使用案例的互動順序，再將這些順序合併至元件設計中。
在每種情況下，建議您以平行方式開發不同的活動，並且在早期階段開發程式碼和測試。 請避免嘗試完成其中一個層面，然後再開始另一個層面。 通常，需求以及您對系統設計最佳方式的了解會在您撰寫和測試程式碼時變更。 因此，您應該從了解和撰寫需求與設計之主要功能的程式碼開始。 您可以在專案的後期反覆項目中填入詳細資料。
了解需求。 任何設計的起點都是清楚了解使用者的需求。
架構模式。 您對系統核心技術和架構項目所做的選擇。
元件及其介面。 您可以繪製元件圖表來顯示系統的主要部分，並且顯示它們用以彼此互動的介面。 每個元件的介面都包含您在順序圖表中識別的所有訊息。
元件之間的互動。 您可以針對每個使用案例、事件或流入訊息繪製順序圖表，以便顯示系統的主要元件如何互動以達到所需的回應。
元件和介面的資料模型。 您可以繪製類別圖表來描述在元件之間傳遞以及儲存在元件內部的資訊。
了解需求
完整應用程式的高階設計實際上通常會搭配需求模型或使用者需求的其他描述一起開發。 如需需求模型的詳細資訊，請參閱模型化使用者要求。
如果您正在開發的系統是較大系統中的元件，您的部分或所有需求可能會包含在程式設計介面中。
需求模型會提供下列基本資訊片段：
提供的介面。 提供的介面會列出系統或元件必須提供給其使用者的服務或作業，不論他們是人類使用者還是其他軟體元件都一樣。
需要的介面。 需要的介面會列出系統或元件可以使用的服務或作業。 在某些情況下，您可以將這些服務都設計成您自己系統的一部分。 在其他情況下，尤其是您要設計可以在許多組態中結合其他元件的元件時，就要依照外部的考量設定需要的介面。
服務需求品質。 系統必須符合的效能、安全性、強固性以及其他目標和條件約束。
需求模型是從系統使用者的觀點撰寫的，不論他們是人員還是其他軟體元件都一樣。 他們完全不了解系統的內部運作。 反之，架構模型的目標則是描述內部運作，並且顯示它們如何符合使用者的需求。
將需求和架構模型分開會很有用，因為這樣做可方便您與使用者討論需求。 它也可以協助您在保持需求不變時重構設計並考慮替代架構。
您可以用兩種替代方式，將需求和架構模型分開：
將它們保存在不同專案的相同方案中。 它們就會在 [UML 模型總管] 中顯示成個別模型。 不同的小組成員可以用平行方式處理這些模型。 您可以在這些模型之間建立有限種類的追蹤。
將它們放在不同封裝的相同 UML 模型中。 這樣做可讓您更輕鬆地追蹤這些模型之間的相依性，不過一次只能有一位人員處理此模型。 此外，非常龐大的模型會花較長的時間來載入 Visual Studio 中。 因此，這種方法較不適用於大型專案。
您應該放入需求或架構模型的詳細資料量取決於專案的規模以及小組的大小和分佈。 負責簡短專案的小型小組可能只會簡略繪製商務概念和一些設計模式的類別圖表，而分佈於多個國家的大型專案則需要更多詳細資料。
架構模式
在開發初期，您必須選擇設計所仰賴的主要技術和項目。 進行這些選擇的區域包括下列各項：
基本技術選擇，例如在資料庫與檔案系統之間選擇，以及在網路應用程式和 Web 用戶端之間選擇等等。
架構選擇，例如在 Windows Workflow Foundation 或 ADO.NET Entity Framework 之間選擇。
整合方法選擇，例如在企業服務匯流排或點對點通道之間選擇。
這些選擇通常是依照服務需求品質 (例如規模和彈性) 來決定，而且可以在得知詳細的需求之前進行。 在大型系統中，硬體和軟體的組態密切相關。
您所做的選擇會影響您使用及解譯架構模型的方式。 例如，在使用資料庫的系統中，類別圖表中的關聯可能代表資料庫中的關聯或外部索引鍵，而在以 XML 檔案為基礎的系統中，關聯可能表示使用 XPath 的交互參照。 在分散式系統中，順序圖表中的訊息可以代表連線上的訊息，而在獨立的應用程式中，它們可以代表函式呼叫。
元件及其介面
這一節的主要建議事項如下所示：
建立元件圖表來顯示您系統的主要部分。
繪製元件或其介面之間的相依性來顯示系統的結構。
使用元件上的介面來顯示每個元件所提供或需要的服務。
在大型設計中，您可以繪製個別圖表，將每個元件分解成較小的組件。
這些重點將詳述於本節的其餘部分中。
元件
架構模型的中央檢視是元件圖表，其中顯示了系統的主要部分以及它們如何彼此相依。 如需元件圖表的詳細資訊，請參閱 UML 元件圖表：參考。
.png "顯示組件的 UML 元件圖表")
大型系統的一般元件圖表可能包括下列元件：
展示。 提供存取權給使用者的元件，通常在 Web 瀏覽器上執行。
Web 服務元件。 提供用戶端與伺服器之間的連線。
使用案例控制器。 指導使用者逐一完成每個情節的步驟。
商務核心。 包含以需求模型中之類別為基礎的類別、實作關鍵作業，並且施加商務條件約束。
資料庫。 儲存商務物件。
記錄和錯誤處理元件。
元件之間的相依性
除了元件本身以外，您也可以顯示它們之間的相依性。 兩個元件之間的相依性箭號會顯示其中一個元件的變更可能會影響另一個元件的設計。 發生這種情況的原因通常是因為某個元件直接或間接使用其他元件所提供的服務或功能。
結構完善的架構會清楚排列相依性，讓下列條件成立：
相依性圖形中沒有任何迴圈。
元件可以排列在圖層中，讓每個相依性從某個圖層中的元件移至下一個圖層中的元件。 任何兩個圖層之間的所有相依性都會按照相同的方向移動。
您可以直接顯示元件之間的相依性，也可以顯示附加至元件之需要和提供的介面之間的相依性。 您可以使用介面來定義每個相依性中使用的作業。 通常，當您先繪製圖表時，就會顯示元件之間的相依性，而在加入更多資訊之後，這些相依性會由介面之間的相依性所取代。 雖然這兩種版本都是軟體的正確描述，不過包含介面的版本會比先前的版本提供更多詳細資料。
對於生產易於維護的軟體而言，管理相依性是最重要的工作。 元件圖表應該要反映出您程式碼中的所有相依性。 如果程式碼已經存在，請確定所有相依性都顯示在圖表中。 如果程式碼正在開發中，請確定它不包含元件圖表中沒有規劃的相依性。 若要協助找出程式碼中的相依性，您可以產生圖層圖表。 若要協助確保符合規劃的相依性條件約束，您可以針對圖層圖表驗證程式碼。 如需詳細資訊，請參閱圖層圖表：參考。
介面
您可以將介面放在元件上，藉以區隔並命名每個元件所提供的主要作業群組。 例如，以網頁為基礎之銷售系統中的元件可能會具有讓客戶用以購買商品的介面、讓供應商用以更新其目錄的介面，以及用以管理系統的第三個介面。
元件可以有任意數目之提供和需要的介面。 提供的介面會顯示此元件提供給其他元件使用的服務。 需要的介面會顯示此元件在其他元件中使用的服務。
如果您同時定義了提供和需要的介面，這樣做有助於您將元件與設計的其餘部分完全區隔開，以便使用下列技術：
將元件放入測試控管中，其中周圍元件是由測試控管所模擬。
獨立開發您的元件，而不需要考量其他元件。
將元件的介面結合至不同的元件，藉以在其他內容中重複使用此元件。
當您想要在某個介面中定義的作業清單時，可以在 UML 類別圖表上建立此介面的另一個檢視。 若要這樣做，請在 [UML 模型總管] 中找出此介面，然後將它拖曳至類別圖表。 接著，您就可以將作業加入至此介面。
UML 介面中的作業可以代表任何用以叫用元件行為的方式。 它可能代表 Web 服務要求、某些其他種類的訊號或互動，或是一般程式函式呼叫。
若要判斷要加入哪些作業，請建立順序圖表來顯示元件之間彼此互動的方式。 請參閱元件之間的互動。 每個順序圖表都會顯示不同使用案例中進行的互動。 您可以用這種方式，在探索使用案例時，逐一加入每個元件介面的作業清單。
將元件分解成組件
您可以將上述章節中所描述的程序套用至每個元件。
您可以將每個元件內部的子元件顯示成組件。 組件實際上就是其父元件的屬性，也是一種類別。 每個組件都具有它自己的型別，可能是元件。 您可以將這個元件放在圖表上並顯示其組件。 如需詳細資訊，請參閱 UML 元件圖表：方針。
將這項技術套用至整個系統會很有用。 您可以將它繪製為單一元件，並將其主要元件顯示成組件。 這樣做有助於您清楚地識別系統與外部環境的介面。
當某個元件的設計使用了另一個元件時，您通常可以選擇要將它表示成組件，還是透過需要之介面存取的個別元件。
在下列情況中，請使用組件：
父元件的設計必須一律使用組件的元件型別。 因此，組件的設計就是父元件的設計不可或缺的一部分。
父元件本身實際上不存在。 例如，您可能會有一個名為「展示層」的概念元件，而它代表處理檢視和使用者互動的實際元件集合。
在下列情況中，請使用透過需要之介面存取的個別元件：
需要的元件可以在執行階段中透過其介面結合至不同的提供元件。
其設計方式可讓您輕鬆地將某個提供者取代成另一個提供者。
使用需要的介面通常會比使用組件更好。 雖然設計可能要花上更久的時間，不過產生的系統會更有彈性。 您也比較容易個別測試元件。 這種設計的開發計劃允許較低的結合程度。
元件之間的互動
這一節的主要建議事項如下所示：
識別您系統的使用案例。
針對每個使用案例，繪製一個或多個圖表來顯示您系統的元件如何透過與其他元件和使用者共同作業，達成所需的結果。 通常，這些都是順序圖表或活動圖表。
使用介面來指定每個元件所接收的訊息。
描述介面中各項作業的作用。
針對每個元件重複此程序，並顯示其組件的互動方式。
例如，在以網頁為基礎的銷售系統中，需求模型可能會將客戶採購定義為使用案例。 您可以建立順序圖表來顯示客戶與展示層中元件之間的互動，並且顯示他們與倉儲和帳戶處理元件之間的互動。
識別起始事件
您可以輕鬆地依照系統提供給不同輸入或事件的回應分割大部分軟體系統所做的工作。 起始事件可能是下列其中一個事件：
使用案例中的第一個動作。 它可能會在需求模型中顯示為使用案例中的步驟或活動圖表中的動作。 如需詳細資訊，請參閱UML 使用案例圖表：方針和 UML 活動圖表：方針。
程式設計介面中的訊息。 如果您正在開發的系統是較大系統中的元件，就應該將它描述成其中一個元件介面中的作業。 請參閱元件及其介面。
系統所監視的特定條件，或一般事件，例如一天內的某個時間。
描述運算方式
繪製順序圖表來顯示元件如何回應初始事件。
針對按照一般順序參與的每個元件執行個體繪製生命線。 在某些情況下，每個型別可能會有多個執行個體。 如果您已將整個系統描述為單一元件，則它所包含的每個組件都應該有一條生命線。
如需詳細資訊，請參閱 UML 順序圖表：方針。
活動圖表在某些情況下也很有用。 例如，如果您的元件具有連續資料流，就可以將它描述為物件流程。 如果您的元件具有複雜的演算法，就可以將它描述為控制流程。 請確定您清楚地指出哪個元件執行每個動作 (例如使用註解)。 如需詳細資訊，請參閱 UML 活動圖表：方針。
指定作業
這些圖表會顯示每個元件所執行的作業，而這些作業會表示成順序圖表上的訊息或活動圖表中的動作。
請針對每個元件一起收集這些作業。 在元件上建立提供的介面，並將這些作業加入至介面。 通常，每種用戶端都會使用不同的介面。 在 [UML 模型總管] 中，您可以用最輕鬆的方式將這些作業加入至介面。 以相同的方式，從其他用元件收集每個元件所使用的作業，並且將它們放置在附加至元件之需要的介面中。
建議您將註解加入至活動或順序圖表，以便指出每項作業之後已經達成的目標。 您也可以在每項作業的 [Local Postcondition] 屬性中撰寫該作業的作用。
元件和介面的資料模型
在元件介面中定義每項作業的參數和傳回值。 如果這些作業代表引動過程 (例如 Web 服務要求)，參數就是做為要求所傳送的部分資訊片段。 如果某項作業會傳回許多值，您就可以使用將 [Direction] 屬性設定為 [Out] 的參數。
每個參數和傳回值都具有型別。 您可以使用 UML 類別圖表來定義這些型別。 您不需要在這些圖表中表示實作詳細資料。 例如，如果您正在描述當做 XML 傳輸的資料，就可以使用關聯來代表 XML 節點之間的任何一種交互參照，並且使用類別來代表節點。
使用註解來描述關聯與屬性的商務條件約束。 例如，如果客戶訂單上的所有項目都必須來自相同的供應商，您就可以透過參考訂單項目與產品目錄項目之間的關聯，以及目錄項目與其供應商之間的關聯，描述這點。
設計模式
設計模式會概述如何設計系統的特定層面，尤其是在系統不同部分中重複出現的層面。 您可以藉由在整個專案中採用統一的方法，降低設計成本、確保使用者介面的一致性，並且降低了解和變更程式碼的成本。
某些一般設計模式 (例如「觀察者」(Observer)) 是已知且廣泛適用的設計模式。 此外，也有僅適用於您專案的模式。 例如，在 Web 銷售系統的程式碼中，有許多作業會對客戶的訂單進行變更。 為了確保訂單的狀態會精確地顯示在每個階段中，這些作業都必須遵循特定的通訊協定來更新資料庫。
軟體架構的部分工作是要判斷在整個設計中應該採用哪些模式。 這通常是持續進行的工作，因為您將會隨著專案進行而發現新的模式以及對現有模式的改良。 建議您組織開發計劃，以便在早期階段中施行每個主要設計模式。
大部分的設計模式都可以部分包含在架構程式碼中。 您可以減少模式的一部分，以便要求開發人員使用特定類別或元件，例如確保正確處理資料庫的資料存取層。
設計模式會描述於一份文件中，而且通常包括下列部分：
名稱。
適用內容的描述。 哪些準則應該讓開發人員考慮套用這個模式？
它所解決之問題的簡短說明。
主要部分及其關聯性的模型。 這些可能是類別或元件和介面，以及它們之間的關聯和相依性。 這些項目通常可分為兩類：
使用此模式時，開發人員必須在程式碼的每個部分中複寫的項目。 您可以使用範本型別來描述這些項目。 如需詳細資訊，請參閱 UML 使用案例圖表：參考。
描述開發人員應該使用之架構類別的項目。
組件之間互動的模型 (使用順序或活動圖表)。
命名慣例。
此模式如何解決問題的描述。
開發人員能夠採用之變化的描述。