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

　　圖7： 預定一輛汽車的分析階段的順序圖

　　你會看到，在這個圖中我已經引入了一個非業務類-UCController。這個用例控制類表示的是一個尚未進一步定義的類，它的職責是從用戶那里接收事件和消息。我發現大多數讀者都會感到困惑：一個業務類(例如出租地點或者預約)來接收用戶的消息?因此我通常會給我的分析交互圖增加一個通用的用例控制類，來表示這個邏輯，而且方便了讀者的理解。在設計階段，我們會把這個類改名為 ReserveAVehicleController，但是現在我用這個通用的名字UCController 來表示。

　　順序圖和交互圖包括幾乎相同的內容，它們只是表示方式不同而已。選用哪一種圖主要取決于是否方便和個人偏好。在順序圖中，對象按豎列對齊，按照從上到下的時間線來順序排列。標了數字和文字的水平線叫做消息。在一個順序圖中，消息的順序用它們的位置來表示：按照時間順序從上到下排列，因此排在下面的消息就在排在上面的消息之后發生。消息從一個對象的時間線上開始，在一條時間線上終止(一般都是另一個對象的時間線)，但是有時也會終止在同一個對象的時間線上，如圖7中的消息21。

　　順序圖與協作圖相比，有一個非常明顯的優點，就是在圖左邊的腳本。這些文字是從用例，或者場景中摘取的，對順序圖的描述。這些描述就是對預約汽車這個用例的一個簡短的描述。通過把這些腳本放在圖邊，使得消息的含義變得非常清晰。而且把消息、對象和原先的用例相結合起來。用例中的每條語句都會對應圖中的一個或多個消息，在順序圖上，這表示的非常清楚。

　　我想強調一下，在分析階段的交互圖中很重要的一點就是：消息表明了意圖，而不是實現，也不是接口在預約汽車順序圖上，消息只是簡單的表明了，我希望接收消息的對象做什么事情，消息并不代表一次函數調用。函數調用這些更具體的信息，會在設計階段確定。但是現在，我們只需要在這個用例中，類的職責。

　　我們如何找出這些消息呢?只要看看我們的職責的定義就可以了。例如，在第八步中，租借地點要決定在這個地點，哪些汽車是可用的。在第九步中，汽車租借要提供在這個地點，能夠滿足用戶要求的日期和時間的所有汽車。在第十步，租借中的每個汽車都需要回答它本身是否滿足某些租借條件。請注意所有這些知識都不在租借地點這個對象中。我們把這些知識分布到了我們的所有分析類當中，因此每個類都可以按照定義來完成一部分工作。

　　UML說明：對象-是否需要命名?

　　在順序圖中，對象框沒有名字“：”，這些對象叫做匿名對象。但是也可以為對象起一個名字。如果我們有一個類叫做Account，我們可以這樣命名：

　　我們可以這樣命名：

　　如果我們建立兩個Account類的實例對象，FredsStash和EthelsMadMoney，它們將是這樣：

　　以左邊的一個為例，表明“FredsStash是Account類型的一個對象”。 如何決定是否給一個對象命名呢?如果系統中的一個實體類，有一個很清楚的名字，你可能想為它的對象起一個名字。如果你的圖中有一個示范的對象(類似于數據模型中的數據表例子)，你也可以用一個有名字的對象。但是對大多數情況來說，匿名對象就足夠了。我們只關系類和對象提供了什么服務，致于對象的名字并不會影響到對象的行為。

　　用例分析第七步：描述屬性和關系

　　在分析中，我們會發現，類為了完成自己的職責，會需要一些屬性(也就是類的屬性變量)。從類的職責列表中，我們可以確定分析類的一些屬性。另外一些屬性要從常識中得出(例如，每個汽車對象應該有一個獨一無二的標識屬性，與實際的汽車上的汽車聯盟的標準汽車編號相對應)。

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