從用例到代碼：用例分析(8)

　　UML 說明：UML中的類在圖上分為三段，以Account類為例，如下圖所示：

　　圖8中的類圖上展示了汽車租借的分析類、它們之間的關系以及每個類所擁有的一些基本的屬性。這些屬性是由類的職責推理得到的一些很明顯的屬性。請注意這些屬性都沒有表明數據類型，因為數據類型是設計階段的問題。

　　圖8： 類屬性的起點

　　在當前這一步中，我們只需要表明顧客類具有一個叫做地址的屬性就足夠了。至于地址這個屬性是什么樣的，甚至需要不需要成為一個獨立的地址類，會在后面的階段中決定。你會發現汽車租借類還沒有屬性，它會變成系統的一個對外的接口。而汽車數據庫需要哪些屬性，則還根本沒有決定。今后的階段會解決這些問題。

　　用例分析第八步：驗證分析機制

　　分析機制指的是高級的系統構建組件，它可以提供解決特定領域問題所需要的一些服務，而不是技術方面。例如，在保險領域，保單中的信息、聲明和其它內容，在整個保險管理期間都是需要的。這個需求用分析機制來說，就叫做：持久化：無論程序是否運行，都一直維護數據的信息和狀態。請注意我們并沒有指定使用Oracle SQL，或是SQL Server這些特定的實現環境，我們只是列出了持久性，和我們后面會談到的設計機制和實現機制。實現機制將會是與特定平臺或者軟件供應商相關的。

　　我們在表4中試著舉例說明，分析、設計和實現機制之間的關系：

　　表4： 說明，分析、設計和實現機制之間的關系

　　一些通用的分析機制是：

　　持久性

　　通訊(進程之間，或是應用程序之間)

　　意外處理

　　事件通知機制

　　消息

　　安全

　　發布(也就是說，被發布的對象)

　　遺留的系統接口

　　在汽車租借系統中，我們需要為這些指定分析機制：

　　結論

　　在“從用例到代碼”的第一部分中，我們從一個用例開始，迄今為止已經找出了用來實現用例的類，它們之間的關系，和它們需要的屬性。我們還找出了一些分析機制，在今后的設計和實現中會用到它。

　　如果我們對另一個用例再一次重復這整個過程，我們會發現另一些分析類，定義它們的職責，它們之間的關系。也許還會發現一些新的分析機制，畫出新的協作圖或是順序圖，來說明這些類如何交互。這演示了RUP過程的遞增的特點：每個任務，每次迭代，都是在前面工作的基礎之上進行的。

原文轉自：http://www.uml.org.cn/Test/200904165.asp