CASE軟件Enterprise Architect教程 ：UML（二）

【點擊下載Enterprise Architect最新版本】

我們在上篇教程UML（一）已經確定UML是一種用于指定軟件系統的工件和交互的語言。我們還看到它涉及6個主要領域，從用例模型，通過動態和邏輯模型到最終的物理部署模型，并且已經包含擴展機制以允許對模型符號進行專門添加。

那么如何使用UML？

UML通常用作軟件開發過程的一部分，在合適的CASE工具的支持下，定義所提出的軟件系統的要求，交互和元素。該過程的確切性質取決于所使用的開發方法。示例流程可能如下所示：

1獲得業務流程模型，將用于定義組織中發生的高級業務活動和流程，并為用例模型提供基礎。所述業務流程模型通常將捕獲比軟件系統更將實現（它包括手動和其它進程）。

2將用例模型映射到業務流程模型，以準確定義您希望從業務用戶角度提供的功能。在添加每個用例時，創建從適當的業務流程到用例（即實現連接）的可跟蹤鏈接。此映射清楚地說明了新系統將提供哪些功能以滿足流程模型中概述的業務要求。它還確保在沒有目的的情況下不存在用例。

3優化用例：包括要求，約束，復雜性評級，注釋和方案。此信息明確地描述了用例的作用，執行方式以及執行的約束。確保用例仍符合業務流程要求。包括每個用例的系統測試定義，以定義每個用例的接受標準。還包括一些用戶驗收測試腳本，用于定義用戶將如何測試此功能以及驗收標準。

4 從業務流程模型的輸入和輸出 以及用例的詳細信息，開始構建域模型（高級業務對象），序列圖，協作圖和用戶界面模型。這些描述了新系統中的“事物”，這些事物的交互方式以及用戶用于執行用例場景的界面。

5從域模型，用戶界面模型和場景圖創建類模型。這是對系統中對象，其數據或屬性及其行為或操作的精確說明?？梢允褂美^承將域對象抽象為類層次結構。場景圖消息通常映射到類操作。如果要使用現有框架或設計模式，則可以導入現有模型元素以在新系統中使用。對于每個類，定義單元測試和集成測試以徹底測試i）該類在內部指定的功能和ii）該類與預期的其他相關類和組件交互。

6隨著類模型的發展，它可以分解為獨立的包和組件。組件表示可部署的軟件塊，用于收集一個或多個類的行為和數據，并向其服務的其他使用者公開嚴格的接口。因此，從類模型 中構建組件模型來定義類的邏輯包。對于每個組件，定義集成測試以確認組件的接口滿足與其他軟件元素相關的規范。

7在您已完成的工作的同時，應該捕獲并記錄其他要求。例如 - 非功能需求，性能要求，安全要求，職責，發布計劃等。在模型中收集這些內容并隨著模型的成熟保持最新。

8部署模型定義了系統的物理結構。這項工作可以盡早開始，以捕獲物理部署特征 - 硬件，操作系統，網絡功能，接口和支持軟件將構成新系統，將在何處部署以及哪些參數適用于災難恢復，可靠性，返回起來和支持。隨著模型的發展，將更新物理架構以反映所提議的實際系統。

9構建系統：獲取模型的離散部分并分配給一個或多個開發人員。在用例驅動的構建中，這將意味著將一個用例分配給開發團隊，讓他們構建執行該用例所必需的屏幕，業務對象，數據庫表和相關組件。隨著每個用例的構建，它應該伴隨著完整的單元，集成和系統測試。組件驅動的構建可能會看到分配給開發團隊的獨立軟件組件以進行構建。

10根據相關模型元素跟蹤測試階段出現的缺陷 - 例如。針對用例的系統測試缺陷，針對類的單元測試缺陷等。跟蹤相關模型元素的任何更改以管理“范圍蔓延”。

11隨著工作的進行，更新和優化模型 - 始終評估變更和模型改進對后續工作的影響。使用迭代方法在離散塊中完成設計，始終評估當前構建，前向要求以及在開發過程中發現的任何發現。

12將完整且經過測試的軟件交付到測試然后生產環境中。如果正在進行分階段交付，那么內置軟件從測試到生產的遷移可能會在項目的整個生命周期內多次發生。

注意：上述過程在描述中必然是簡短的，并且沒有說明，并且可能不是您的工作方式或遵循您采用的過程。它是作為UML如何用于支持軟件開發項目的示例給出的。

想要購買Enterprise Architect正版授權的朋友可以。

有關產品動態更多的精彩內容，敬請關注下方的微信公眾號▼▼▼