Vincent.Chan‘s Blog

級別: 初級

Granville Miller, 顧問, TogetherSoft

2001 年 5 月 15 日

Granville Miller 在其新專欄的第一部分中介紹了“統一建模語言”(UML) 的一個構件：序列圖。在整個設計過程中都會用到序列圖，此圖用于演示系統執行時參與者與對象之間的內部交互。讓我們跟著 Granville 一起創建其中一個圖，我們將使用一個貸款處理應用程序作為示例。

統一建模語言 (UML) 是用于建立面向對象系統模型的標準標記法。在 1995 到 1997 年之間，UML 登上了面向對象編程社區的舞臺，而且在 1997 年后期受到了對象管理組織 (OMG) 的認可。雖然它最初頗受爭議 -- 因為它是在一片支持和反對聲中提出的 -- 但 UML 以后卻成為系統標記法的行業標準。UML 的當前版本是 1.4，而且它將不斷發展以滿足面向對象開發人員的需要。（有關 UML 歷史的詳細信息，請參閱 參考資料。）

UML 可能難以學習，主要因為它試圖為相當廣泛的情況提供建模標記法。每種建模標記法都采用一種圖，而目前在 UML 規范中有九種圖。幸好，學習 UML 可以是一個漸進過程；每次可以只學習一種圖，首次試用時不必包含圖中非常復雜的東西。

在本專欄中，我將教您逐步學習基于 Java 應用程序開發的 UML 設計和標記法。我將以邏輯（可能是另人愉快的）方式介紹 UML 框架和其它建模技術的基礎知識，您將通過建立現實示例的模型來學習實際操作。在第一部分中，我們使用貸款處理應用程序作為示例，從建立序列圖開始。請注意，假設您熟悉 Java 語言，而且掌握了面向對象方法和術語的基礎知識。本專欄將簡要說明面向對象的概念，但不會進行深入討論。

關于序列圖

關于參與者角色 參與者角色有助于發現和標識可以參與到用例方案中的參與者。一個參與者在一個用例和多個用例中可以有多個角色。目前，已經將四種不同的參與者角色標識成 UML 的增強或傳統角色：啟動程序、服務器、接收方和代理。因為可以在序列圖中反映參與者角色，所以您應該熟悉它們的功能。 啟動程序是設置行動中某個系統行為的外部實體。啟動程序可以請求服務或生成事件。在顯示參與者的序列圖中，啟動程序啟動了行動中的序列。 外部 服務器角色為其它角色提供服務。服務器通過在外部提供功能或信息來幫助系統實現其目標。許多包含了操作系統的外部系統都是服務器角色。服務器會接收消息，但也許不會生成消息。 接收方角色接收來自系統的信息。它們以消極方式提供服務。因此，它們可能不會向系統提供值，但會想其它參與者提供值。接收方的一個示例就是數據倉庫或外部備份系統。接收方通常接收來自系統中對象的消息，但一般不會生成消息。 代理是代表另一個參與者執行操作的參與者。代理的一個示例就是代表顧客租借錄影帶的音像店職員。

UML 沒有排斥任何特殊的軟件開發方法或過程；它只不過標準化了標記法的格式。然而，許多開發方法都合并了 UML。Rational 統一過程 (RUP) 就是這樣一種方法；另一種方法是功能驅動的開發 (FDD)。由于其直觀性和通用性，UML 序列圖已成為這些過程的前端建模活動的一部分。序列圖用于建立以下內容的模型：

• 用例方案
• 框架中的協議
• 子系統
• 類
• 方法邏輯

以下是上述每個功能的簡要說明。

用例方案
對于示例應用程序，我們將使用序列圖來建立單個用例方案的模型。用例是由參與者與應用程序交互為實現某個指定目標而執行的單個任務。參與者可以是與應用程序交互、在應用程序外部的任何最終用戶、組織或系統。（要了解四種參與者角色，請參閱 關于參與者角色；如需關于用例方案的深入討論，請參閱 參考資料。）

框架中的協議
協議位于框架及其稱作 集合體的可交換組件之間。了解框架必需的交互有助于開發新的集合體。序列圖通常用于記錄這些交互。

子系統
大的項目被分解成更小且易管理的部分，稱作 子系統。子系統之間的接口關于將它們集成成為更大的整體（即，系統）是至關重要的。序列圖用于指定子系統邊界上的類之間的交互。

類
某些類（如 Socket 和 InetAddress ）需要一個復雜的方法調用序列，以便正確交互。這些序列組成了用于與這樣的某個類或一組類交互的協議。序列圖可用于描述類或一組相互作用的類的使用，因而描述了交互所需的協議。

方法邏輯 序列圖在記錄方法邏輯方面非常優秀。實際上，只要給出了 Java 方法，某些 CASE 工具會自動生成一個序列圖。序列圖可用于設計未來方法或記錄現有方法的流程。

回頁首

關于示例應用程序

我們將在示例貸款處理應用程序的幫助下學習序列圖。因為本專欄的重點在于建模，而不是方法，我們要直接討論建立圖，所以我們不會注重于應用程序的細節。我們為貸款處理應用程序繪制的基本功能如下：

用例：提交貸款請求

1. 申請人通過因特網完成并向銀行提交貸款申請。
2. 系統確認貸款申請的信息，檢查它是否正確以及信息是否盡可能完整。
3. 系統向外部商業資信咨詢機構轉發貸款請求，以獲取該申請人的信用報告。
4. 系統根據所返回的信用報告計算申請人的信用積分。

回頁首

入門

創建序列圖的第一步是確定該圖是否表示與外部或內部實體的交互。如果正在建立用例方案的模型，那么序列圖通常表示與外部實體的交互。如果正在建立框架中協 議的模型，那么此圖也許表示內部或外部交互。子系統圖、類圖和個別方法邏輯圖通常只表示內部實體。無論是哪種情況，將要建模的交互類型決定了序列圖中的第 一個（最左邊的）元素。

與外部實體的交互表示參與者是交互的一部分。內部交互可能由參與者啟動（如果子系統用例是交互的基礎），但它更可能是由叫作 Sender 的普通類啟動的。如果參與者啟動了交互，那么參與者將歸入啟動程序類別，這是四種常見參與者角色之一（有關詳細信息，請參閱 關于參與者角色）。

我們將關注為貸款處理應用程序（以上概述的 提交貸款請求用例）的方案建立圖。請注意當申請人完成在線貸款申請并在因特網上提交它時序列圖的變化。在這個方案中，申請人在系統外部，因此用參與者來表示他。我們首先將參與者 Applicant 添加到序列圖，如圖 1 所示。

添加參與者
一旦交互的啟動程序就位，下一步就是添加它在方案的過程中將與之交互的對象。這些對象的名稱應該反映出類或實例的行為。（類或實例的選擇給出了與序列圖截然不同的含義，但我將把這兩者之間差異保留到下次討論。）

對于示例方案，我們將添加兩個類： LoanApplication 和 LoanRequest 。當申請貸款時，需要提交貸款申請。它包含了關于申請人和期望貸款金額的信息。貸款請求是銀行向商業資信咨詢機構發送的關于接受貸款申請的表單。它包含了來自貸款申請的一些信息，以及獲取關于申請人的信用歷史記錄信息的請求。圖 2 中顯示了將這兩個類添加到序列圖中。

連接各點 -- 虛線
對于大多數軟件開發人員來說，序列圖是直觀的。它們將對象和參與者（橫軸）映射到時間（縱軸）。消息連接了對象，當消息發生時，它們沿著縱軸從一個對象移動到另一個對象。這些消息被連接到從對象或參與者底部的中間延伸出的豎直虛線。這條線被稱作 生命線。

在橫軸上，我們用被稱作 調用箭頭或 消息箭頭的 箭頭來表示消息。消息箭頭從發送方（尾）指向接收方（頭）。這些箭頭用于捕捉系統的動態行為。調用通常始于左邊，向右邊移動。即，交互中的初始箭頭通常來 自左邊。當創建類的新實例時，我們繪制的箭頭都指向類自身，而不是生命線。我們方案中的第一步是創建新的貸款申請，因此我們在 Applicant 和 LoanApplication 之間畫出箭頭。由于用 Java 創建新實例涉及到調用構造器，因此我們將這個箭頭標上構造器名稱，可能的話，還要標上變量。

我們仍處于軟件開發生命周期中的分析階段，因此我們要僅可能多地包含分析信息。我們的一個商務分析員提到我們把創建新貸款申請的操作稱作“完成貸款申請”。如果我們要在構造過程中使這個序列圖保持為真，那么可以將 complete 實現成公用方法，它將調用 LoanApplication 構造器，如圖 3 所示。

建立某個活動的圖
但類或實例接收到消息時，它會在接收對象的生命線上創建一個框；這個框稱作 活動。活動表示接收方的方法中的控制權流向。當消息導致創建了一個對象時，第一個活動表示構造器的邏輯。隨后的消息將導致創建新的活動。

但接收到消息時，接收對象可以依次將消息發送到它自身或其它對象。這由箭頭的尾巴顯示，它表示箭頭源于活動，而終止于新的活動。但對象調用自身時，新的活動將放到舊活動之上。

在此方案中，申請人與貸款申請交互兩次，第一次是完成它，而第二次是提交它。當 LoanApplication 接收到 submit 消息時，它會通過將 validate 消息發送到自身來驗證它自己。如果有效，則它會創建要發送到商業資信咨詢機構的新 LoanRequest 。圖 4 顯示了 LoanApplication 的驗證過程。

箭頭文件：表示時間流逝
我們使用斜向箭頭來表示消息發送和接收之間的真實時間的流逝。這種標記法用于顯示非基本調用。非基本調用的示例是經由 CORBA 或 RMI 進行的方法調用，或是在網絡上發送的消息。

在此示例中，商業資信咨詢機構是一個外部系統，它是具有服務器角色的參與者（有關詳細信息，請參閱 關于參與者角色）。 服務器通常不生成消息，但會有發送給它們的消息 -- 在本例中是由信用檢查器發送的信用報告的請求。信用檢查器代表了商業資信咨詢機構。它跟蹤請求并將請求轉發給商業資信咨詢機構，跟蹤并接收響應，此外就是 建立貸款處理應用程序和商業資信咨詢機構之間的連接。商業資信咨詢機構將接收請求，并根據它自己的時間表處理請求。我們使用斜向箭頭表示這段時間的流逝， 如以下的圖 5 所示。

在活動的結尾，返回到調用程序的結果是隱式的。然而，在某些情況下，您可能希望返回是顯式的。顯式返回調用由虛線箭頭表示，該箭頭的尾巴是接收方，頭是發送方。顯式返回箭頭通常由調用返回的值標記。對于此示例，我們已經在 CreditBureau 和 CreditChecker 之間添加了顯式箭頭。這個箭頭可以是帶標簽的 CreditReport ，因為它是從 requestCreditReport 方法返回的對象。

下一步
我在本文開頭已經提到過，序列圖用于描述系統運行時的內部行為。在本文中，我已經介紹了通過建立對象間交互的模型來構建序列圖的第一步。在下一部分中，我將介紹兩種序列圖（常規和實例），并使用根據簡單的 Java 方法繪制的示例說明條件邏輯在序列圖中的角色。到時候見！

回頁首

參考資料

• 您可以參閱本文在 developerWorks 全球站點上的 英文原文.
  
  
• 單擊本文頂部或底部的 “討論”參加關于本文的 討論論壇。
  
  
  
• Martin Fowler（ UML Distilled 的作者）提供了 UML 早期歷史的 內幕。
  
  
  
• Fowler 的“ 為什么使用 UML”進一步說明了開發周期中對標準化標記法的需要（Software Development Online，2000 年 3 月）。
  
  
  
• 如果您想要認真學習 UML，那么應該從三個朋友（Booch、Jacobson、Rumbaugh）撰寫的原文開始： 統一建模語言用戶指南 （Addison Wesley Object Technology Series，1998）。
  
  
  
• 接下來應該學習的基本讀物是 OMG 的 統一建模語言規范（2001 年 2 月時的版本是版本 1.4）。
  
  
  
• Rational 的 UML 資源頁面提供了關于 UML、RUP 的信息以及其它內容。
  
  
  
• 有關序列圖和 UML 的額外信息，請參閱 " 建立帶有樣式的 UML 序列圖"，由 Scott W. Ambler 著（developerWorks，2001 年 2 月）。
  
  
  
• Allen Holub 在他有關面向對象設計過程的系列中提供了 用例方案的深入說明（developerWorks，2001 年 1 月）。
  
  
  
• 如果要更深入地研究用例建模，請參閱 Frank Armour 和 Granville Miller 合著的 " Advanced Use Case Modeling, Volume I: Software Systems"（Addison-Wesley，2001）。
  
  
  
• 如需關于功能驅動的開發和 Rational 統一過程的優秀讀物，請參閱 Peter Coad、Eric Lefebvre、Jeff DeLuca 合著的 Java Modeling in Color with UML （Prentice Hall，1999）。
  
  
  
• 關于 RUP 的另一本好書是 Philippe Kruchten 撰寫的 The Rational Unified Process: An Introduction （Addison Wesley，2000）。
  
  
  
• 請閱讀 OCL，它是 UML 的表達式語言。
  
  
  
• IBM 和其它一些業界領先者創建了 XMI，一種新的開放業界標準，它將一些基于 Web 的用于編輯、確認和共享文檔格式等 XML 標準的優點和 UML 的優點結合了起來。
  
  

回頁首

關于作者

	Granville 加入面向對象社區已有 13 年了。他是 高級用例建模 (Advanced Use Case Modeling) 系列的合著者，并在全世界范圍的各種面向對象技術會議中介紹過教程。他的面向對象開發的實踐方法來自于他在多家公司供職的經驗，其中包括從處于創業階段的公司到相當成熟的軟件業巨擘在內的各種公司。 他目前正在教授有關靈活過程、方法和 Java 技術的研習班、教程和課程，同時還在輔導和幫助實現一些積極的項目。可以通過 rmiller@togethersoft.com 與 Granville 聯系。