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

　　整合所有的用例實現

　　建立跟蹤機制

　　建立分析機制

　　對用例分析的結果進行評估

　　請注意這些步驟的次序不是一成不變的。 你實際所采用的次序取決于你對于分析的領域的理解程度、你對RUP或UML的經驗、你所采用的模型、或者是你自己的確定分析類的屬性的一種習慣方式。(例如，以職責為中心，以行為為中心，或者以數據為中心) 關鍵只在于你是否能夠對問題建立一個準確的描述，而不是對我們的用例設計的準確描述--這將是本文的第二部分的內容)。我會遵循本文中的大多數(但不是全部)步驟，而且我會改變一些步驟的次序。在每個步驟的具體內容中，我會說明為什么這樣做有助于RUP和OOAD的新手更好的學習OOAD。

　　如圖3所示，一些步驟把編寫用例和實現代碼分隔開了。還列出了RUP中用例分析部分推薦使用的一些步驟。這張圖將會指出在后面部分中，我們的前進方向。

　　圖3：用例分析的步驟

　　用例分析第一步：建立一個用例實現

　　RUP中的用例分析過程的第一步是建立一個用例實現。在我們給出用例實現的定義之前，回過頭來看一下，到底什么是用例?我們需要怎樣來確認用例?我們寫好的用例，是一個業務過程的描述，描述了顧客預約汽車的過程。它說明，我們會按照一些固定的步驟，按照固定的業務規則(例如在得到顧客的姓名之前不進行任何處理)，也不為顧客提供那些無法按照指定的時間地點供客戶租用的汽車的信息。

　　由于我們是在設計一個面向對象的軟件系統，我們的用例行為需要由我們系統中的一些對象和類來執行。但是迄今為止，我們還沒有任何對象和類，因此我們需要從用例中去發現這些對象和類。還需要指定每個類要執行用例圖中的哪些行為。

　　如圖4所示，用例實現實際上是一組UML圖，說明了我們都需要哪些類、它們的職責和它們的實例對象之間如何進行交互，來完成用例中的行為。

　　圖4： 機票預訂系統中的一個RUP用例實現

　　通常一個用例實現會由下面這些組成：

　　包括我們所關注的用例中出現的所有類的一個UML類圖(有時也叫做合作類視圖), 和描述交互的對象，以及它們之間的調用關系的一個或多個UML交互圖 。UML定義了兩種類型的交互圖：順序圖 (如圖4)，和協作圖。都很有效。

　　看起來我們有很多事情需要處理，是這樣嗎?是的，而且當你使用諸如Rational Rose或Rational XDE這樣的開發工具的時候，這項工作看起來更像一項家務管理工作，你只需要建立很多結構，存放你的用例實現。后面我們會完成實際的類和交互圖。但是現在我們先來明確一下我們的目標：一個類圖，一個或多個交互圖。

　　用例分析第二步：補充用例描述

　　當你在進行分析的時候，你的用例描述只記錄了從系統外面的用戶角度來看，系統的行為是什么樣子的。在概要的描述系統內部的一些不可見的操作的時候，這足夠了，但是按照這樣的描述，并不能完成具體的實現。

　　舉一個例子，看看上面描述的第四步：系統列出在指定時間、地點和可用的所有符合條件的汽車。如果顧客需要某輛汽車的更詳細的信息，系統也可以提供。在這里，我們有可供搜索汽車信息的數據庫了嗎?我們也許知道，汽車信息由CICS(客戶信息控制系統)管理，存放在MVS主機上，通過LU6.2 APPC可以訪問，但是我們不能確定這一點。讓我們來把這些我們要做的事情，特別是在我們系統之外事情的細節，來清楚的確定下來，而不是只知道我們希望怎樣做。下面是補充了這些信息的第四步，補充一個汽車數據庫： 系統通過訪問這個汽車數據庫來查找汽車的位置信息，并列出在指定時間地點和可用的所有汽車。

　　這里我們給出了一個汽車數據庫的信息，并且比較抽象的描述了如何用網頁來訪問它。這是一個很簡單的例子，但是讀者可以從中了解一些內容。

　　在RUP這樣的迭代開發流程中，從分析階段轉移到設計階段只用了很少的時間。對一個中等規模的，四周左右的項目來說，你可能第一周用來獲取需求， 做你的分析和設計，然后后面3周都用來寫代碼和進行測試。你用于分析的用例會側重于系統對外可見的行為，不過你可能需要細化這些用例的描述，增加更多的系統內部如何交互的描述。這樣你的顧客和分析人員才能確認你沒有遺漏一些重要的業務。請注意，只需要把用例描述細化到你可以很好的找出系統中的分析類的程度就可以了。 對于設計級別的類(諸如樹、堆棧、隊列、集合等等)可以在后面的階段完成(如設計階段)。

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