共用方式為


建立應用程式架構模型

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

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

模型的目的是減少自然語言描述中出現的模糊性,並協助您和您的同事視覺化設計並討論替代設計。 模型應與其他文件或討論一起使用。 模型本身並不代表架構的完整規格。

備註

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

系統的架構可以分為兩個領域:

  • 高級設計。 這描述了主要組件以及它們如何相互交互以滿足每個要求。 如果系統很大,則每個元件可能都有自己的高階設計,以顯示它如何由較小的元件組成。

  • 在整個元件設計中使用的設計模式和慣例。 型樣描述了實現程式設計目標的特定方法。 透過在整個設計中使用相同的模式,您的團隊可以降低進行變更和開發新軟體的成本。

高級設計

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

如果您要更新現有的程式碼,您可以先描述主要元件。 請確定您瞭解使用者需求的任何變更,然後新增或修改元件之間的互動。 如果您正在開發新系統,請先了解用戶需求的主要功能。 然後,您可以探索主要使用案例的互動序列,然後將序列合併到元件設計中。

在每種情況下,並行開發不同的活動並在早期階段開發代碼和測試是有幫助的。 避免在開始另一個方面之前嘗試完成這些方面之一。 通常,當您編寫和測試程式碼時,需求和您對設計系統最佳方式的理解都會發生變化。 因此,您應該首先了解和編碼需求和設計的主要特徵。 在專案的後續迭代中填寫詳細資料。

  • 了解要求。 任何設計的出發點都是對使用者需求的清晰了解。

  • 建築模式。 您對系統的核心技術和架構元素所做的選擇。

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

了解要求

完整應用程式的高階設計與需求模型或其他使用者需求的描述一起開發得最有效。 如需需求模型的詳細資訊,請參閱 模型使用者需求

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

需求模型提供下列重要資訊:

  • 提供的介面。 提供的介面列出了系統或元件必須提供給其使用者的服務或操作,無論他們是人類使用者還是其他軟體元件。

  • 必要的介面。 必要的介面會列出系統或元件可以使用的服務或作業。 在某些情況下,您將能夠將所有這些服務設計為自己系統的一部分。 在其他情況下,特別是如果您正在設計一個可以與許多組態中的其他元件組合的元件,則所需的介面將由外部考量來設定。

  • 服務質量要求。 系統必須符合的效能、安全性、穩健性,以及其他目標和限制。

    需求模型是從系統使用者的觀點撰寫的,無論他們是人員還是其他軟體元件。 他們對您系統的內部運作一無所知。 相反地,您在架構模型中的目標是描述內部運作,並顯示它們如何滿足使用者的需求。

    將需求和架構模型分開很有用,因為它可以更輕鬆地與使用者討論需求。 它還可以幫助您重構設計並考慮替代架構,同時保持需求不變。

    您應該放入需求或架構模型中的詳細資料量取決於專案的規模,以及小組的規模和分佈。 一個小型專案的小團隊可能只不過是繪製商業概念和一些設計模式的類圖;分佈在多個區域的大型專案需要更多細節。

建築模式

在開發的早期,您必須選擇設計所依賴的主要技術和元素。 必須做出這些選擇的領域包括:

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

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

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

    這些選擇通常由服務品質要求(例如規模和靈活性)決定,並且可以在知道詳細要求之前做出。 在大型系統中,硬體和軟體的配置是高度相互關聯的。

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

設計模式

設計模式是設計軟體中某特定層面的指導原則,尤其是在系統中多處重複出現的模式。 透過在整個專案中採用統一的方法,您可以降低設計成本,確保使用者介面的一致性,並降低理解和更改程式碼的成本。

一些通用的設計模式,如Observer,是眾所周知的,適用範圍很廣。 此外,有些模式僅適用於您的專案。 例如,在網路銷售系統中,程式碼中會有數個操作,其中會變更客戶的訂單。 為了確保訂單狀態在每個階段都能準確顯示,所有這些操作都必須遵循特定的協定來更新資料庫。

軟體架構的部分工作是確定在整個設計中應採用哪些模式。 這通常是一項持續的任務,因為隨著專案的進展,將發現新模式和對現有模式的改進。 組織開發計劃很有幫助,以便您在早期階段練習每個主要設計模式。

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

設計模式在文件中說明,通常包括下列部分:

  • 名稱.

  • 適用內容的描述。 開發人員應該考慮應用此模式的標準是什麼?

  • 簡要解釋它解決的問題。

  • 主要部分及其關係的模型。 這些可能是類別或元件和接口,它們之間具有關聯和依賴關係。 這些元素通常分為兩類:

  • 命名慣例。

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

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