共用方式為


模型化應用程式架構

若要協助確保您的軟體系統或應用程式符合使用者的需求,您可以在 Visual Studio 中建立模型,做為軟體系統或應用程式之整體結構和行為的描述之一部分。 您也可以使用模型來描述整個設計所使用的模式。 這些模型可協助您了解現有架構、討論變更,並清楚地傳達您的意圖。

若要查看哪些 Visual Studio 版本支援這項功能,請參閱 架構和模型化工具的版本支援

模型的目的是要減少自然語言描述中所發生的語意模糊,並且協助您和同事將此設計視覺化以及討論替代設計。 模型應該搭配其他文件或討論一起使用。 模型本身無法代表完整的架構規格。

注意

在本主題中,「系統」表示您正在開發的軟體。 它可能是許多軟體和硬體元件的大型集合、單一應用程式,或應用程式的一部分。

系統的架構可以分成兩個區域:

  • 高階設計。 這會描述主要元件以及它們如何彼此互動以完成每項需求。 如果此系統很龐大,則每個元件可能會有自己的高階設計,其中顯示它如何由較小的元件組成。

  • 設計模式和慣例,於整個元件設計中所使用。 模式會描述達成程式設計目標的特定方式。 只要在整個設計中使用相同的模式,您的小組就可以降低進行變更和開發新軟體的成本。

高階設計

高階設計會描述您系統的主要元件以及它們如何彼此互動以達成設計的目標。 下列清單中的活動與高階設計的開發有關,但是不一定有特定順序。

如果您正在更新現有的程式碼,可能要從描述主要元件開始。 請確定您了解對使用者需求所做的任何變更,然後再加入或修改元件之間的互動。 如果您正在開發新的系統,請從了解使用者需求的主要功能開始。 然後,您可以探勘主要使用案例的互動順序,然後將這些順序合併到元件設計中。

在每種情況下,最好是平形開發不同活動,並且在早期階段開發程式碼和測試。 請避免嘗試完成其中一個層面,然後才開始另一個層面。 通常,需求和您對系統設計最佳方式的了解會在您撰寫和測試程式碼時變更。 因此,您應該先從了解需求與設計之主要功能,並為其撰寫程式碼開始。 您可以在此專案的後期反覆項目中填入詳細資料。

  • 了解需求。 任何設計的起點都是清楚了解使用者的需求。

  • 架構模式。 您對此系統核心技術和架構項目所做的選擇。

  • 元件和介面的資料模型。 您可以繪製類別圖來描述在元件之間傳遞以及儲存在元件內部的資訊。

了解需求

在搭配需求模型或使用者需求之其他描述的情況下,開發完整應用程式的高階設計最為有效。 如需需求模型的詳細資訊,請參閱模型使用者需求

如果您正在開發的系統是較大系統中的元件,您的部分或所有需求可能會包含在程式設計介面中。

需求模型會提供下列必要的資訊片段:

  • 提供的介面。 提供的介面會列出系統或元件必須提供給其使用者的服務或作業,不論他們是人類使用者還是其他軟體元件都一樣。

  • 必要的介面。 必要的介面會列出此系統或元件可以使用的服務或作業。 在某些情況下,您可以將這些服務全部都設計成您自己系統的一部分。 在其他情況下,特別是當您要設計可以在許多組態中結合其他元件的元件時,就要依照外部的考量設定必要的介面。

  • 服務需求品質。 系統必須符合的效能、安全性、加強性以及其他目標和條件約束。

    需求模型是從系統使用者的觀點撰寫的,不論他們是人類還是其他軟體元件都一樣。 他們完全不了解您系統的內部運作。 相反地,架構模型的目標則是描述內部運作,並且顯示它們如何符合使用者的需求。

    將需求和架構模型分開會很有用,因為這樣做可讓您與使用者便於討論需求。 它也可以協助您在保持需求不變的情況下重構此設計並考慮替代架構。

    您應該要放入需求或架構模型的詳細資料量取決於專案的規模以及小組的大小和分佈。 對簡短專案的小型小組而言,頂多只要簡述商務概念和某些設計模式的類別圖即可;而分散在多個區域的大型專案可能會更加需要詳細資料。

架構模式

在開發初期,您必須選擇此設計所仰賴的主要技術和項目。 進行這些選擇的區域包含下列各項:

  • 基本技術的選擇,例如在資料庫與檔案系統之間選擇,以及在網路應用程式和網頁用戶端之間選擇等等。

  • 架構的選擇,例如在 Windows Workflow Foundation 或 ADO.NET Entity Framework 之間選擇。

  • 整合方法的選擇,例如在企業服務匯流排或點對點通道之間選擇。

    這些選擇經常是依照服務需求品質 (例如規模和彈性) 來決定,而且可以在得知詳細的需求之前進行。 在大型系統中,硬體和軟體的組態密切相關。

    您所做的選擇會影響您使用及解譯此架構模型的方式。 例如,在使用資料庫的系統中,類別圖中的關聯可能代表資料庫中的關聯或外部索引鍵,而在以 XML 檔案為基礎的系統中,關聯可能表示使用 XPath 的交互參考。 在分散式系統中,循序圖中的訊息可以代表連線上的訊息,而在獨立的應用程式中,它們可以代表函式呼叫。

設計模式

設計模式會概述如何設計此軟體的特定層面,特別是在系統不同部分中重複出現的層面。 您可以藉由在整個專案中採用統一的方式,降低設計成本、確保使用者介面的一致性,並且降低了解和變更程式碼的成本。

某些一般設計模式 (例如「觀察器」) 是已知且廣泛適用的設計模式。 此外,也有僅適用於您專案的模式。 例如,在 Web 銷售系統程式碼中會有一些作業,其中的客戶訂單受到變更。 為了確保此訂單的狀態會精確地顯示在每個階段中,這些作業全部都必須遵循特定的通訊協定來更新該資料庫。

軟體架構的部分工作是要判斷在整個設計中應該採用哪些模式。 這通常是持續進行的工作,因為您將會隨著專案進行而探索出新的模式以及對現有模式的改良。 最好是組織開發計劃,以便在早期階段中執行每個主要設計模式。

大部分的設計模式都可以部分包含於架構程式碼中。 模式中有一部分可以簡化為要求開發人員使用特定類別或元件,例如確保正確處理資料庫的資料存取層。

設計模式會在一份文件中加以描述,而且通常包含下列部分:

  • 名稱。

  • 適用內容的描述。 哪些準則應該會讓開發人員考慮套用這個模式?

  • 它所解決之問題的簡短說明。

  • 主要部分及其關聯性的模型。 這些可能是類別或元件和介面,以及它們之間的關聯和相依性。 這些項目通常可分為兩類:

  • 命名慣例。

  • 此模式會如何解決問題的描述。

  • 開發人員能夠採用之變化的描述。