繪製循序圖前必須完成的三件事

穩健分析之後，SA會重新檢驗並同步更新使用案例模式和領域模式，下一步就可以進入循序圖了。

循序圖（sequence diagram）可以用來表達資訊系統內部一群物件之間的互動行為，在《Use Case Driven Object Modeling With UML: A Practical Approach》書的十五條分析癱瘓警訊中，編號10到12這三條是跟互動模式有關的警訊。

分析癱瘓警訊10在你對這些物件一無所知之前，別想要為它們配置行為。（Don't try to allocate behavior among objects before you have a good idea what the objects are.）

當參與者來使用系統時，會引發系統內部一群物件的互動，經由物件之間的合作及互動，系統才能夠提供參與者所需的服務或產出，而這也是循序圖要呈現的重點。系統分析師在繪製循序圖時，可以使用簡單的擬人化技巧，把物件當人看，先去了解物件，然後為物件安排適當的行為。

分析癱瘓警訊11在你完成相關的穩健圖之前，別動手繪製循序圖。（Don’t start drawing a sequence diagram before you’ve completed the associated robustness diagram.）

當系統分析師完成了穩健分析，並且同步更新了使用案例敘述以及類別圖之後，就可以依據穩健圖的初步設計，開始動手繪製循序圖，以呈現出系統內部一群物件的互動情況了，如圖1所示。

圖1：循序圖


分析癱瘓警訊12別將焦點放在存取方法上，而是該關注真正的方法。（Don’t focus on get and set methods instead of focusing on real methods.）

由於，物件具有封裝性，所以外界無法直接使用物件的屬性，最好是透過公開的存取方法（get and set method），來存取屬性。也正因如此，所以存取方法可以說是跟隨著屬性而存在，只要定義了屬性，也就相當於同時決定了存取方法。

所以，別浪費時間在存取方法上頭，而是要將時間花在決定真正重要的方法上頭。

以圖2的訂單類別為例，「計算金額」的方法就要比其他的存取方法重要多了，應該優先找尋。

圖2：訂單類別


繪製循序圖該記得的十項要點
雖然，UML2一共有十三款圖，但是對於UML初學者而言，其實僅需要優先學會類別圖、使用案例模式和循序圖，就可以參與UML專案了。雖然，UML2一共有十三款圖，但是對於UML初學者而言，其實僅需要優先學會類別圖、使用案例模式和循序圖，就可以參與UML專案了。在前面的文章中，我們已經談過了類別圖和使用案例模式，現在就剩下循序圖了。原著作者談到了十項繪製循序圖時該注意的地方，很值得UML初學者參考，讓我們一塊來看看吧。

要點1你需要為每一個使用案例，繪製一張循序圖。（You need to do one sequence diagram for each use case.）

要點2循序圖必須符合使用案例的敘述流程。（The daigram should match the narrative flow of the associated use case.）

現在的UML/OOAD專案，幾乎都以使用案例為行為單位（behavior unit），所以每一個使用案例不僅會對應一張穩健圖，還會對應一張循序圖。至於，循序圖中一群物件的互動順序，當然就得符合使用案例敘述中所記錄的主要流程與替代流程了。

我在實務上常遇到的問題是，遇到包含關係和擴充關係時，要怎麼辦？如果還是維持一個使用案例對應一張循序圖的話，那該如何表達使用案例之間的關係呢？

在《The Elements of UML 2.0 Style》一書中，該書的作者有提到遇到呼叫使用案例時，可以使用《include》字標。比方來說，遇到像圖3的使用案例圖，在查詢餘額的循序圖中，就可以呼叫檢驗晶片金融卡使用案例，如圖4所示。

圖3：使用案例圖


圖4：查詢餘額的循序圖


不過，大部分的UML工具都不支持將使用案例的橢圓放置於循序圖中，也就是說，循序圖中是不能呼叫使用案例的。最主要的因素在於，循序圖與使用案例是兩個不同的觀點，循序圖在表達系統內部物件互動的情況，而使用案例則代表系統外部使用者參與系統流程的情況。

另一個方法是，善用UML2提出的框架與片段，讓查詢餘額的循序圖引用檢驗晶片金融卡的循序圖。首先，先使用sd標示的框架圍住一個互動片段或整張循序圖，讓圍住的部分成為可以重用的互動片段，如圖5所示。

圖5：檢驗晶片金融卡的循序圖


然後，使用標示ref的空框架，並於空框架內部標示出欲引用的片段名稱，就意謂著引用了某一份已經定義好的互動片段。請看到圖6，我們在查詢餘額的循序圖中，引用了圖5的檢驗晶片金融卡。

圖6：查詢餘額的循序圖


如果，自動櫃員機又多了一個提款的使用案例，而且提款使用案例與檢驗晶片金融卡之間也有包含關係，如圖7所示。這個時候，系統分析師就可以很快產出另一張對應提款使用案例的循序圖，同樣也引用圖5這張檢驗晶片金融卡的循序圖。

圖7：增加了提款使用案例


圖8：提款的循序圖


要點3如果情況許可的話，為一個完整的使用案例繪製一張單獨的循序圖，圖內要包含所有的替代程序。只有在使用案例變得難以維護的時候，才能夠切分這張單獨的循序圖。（Whenever possible, do a single sequence diagram for the entire use case, including all alternative courses of action. Split the diagram only when a single diagram for the use case get too difficult to manage.）

這項要點已經說明很清楚了，先是一個使用案例對應一張循序圖，包含主要流程和所有的替代流程，複雜到難以維護，或者是難以閱讀時，才切分這張循序圖。

實務上，如果遇到替代流程比較複雜的情況，我也會建議把替代流程獨立出來，繪製成另一張循序圖，這樣會有助於閱讀與理解。

要點4物件之間的訊息會引發類別裡的操作。（Messages between objects invoke the operations on the classes.）

在循序圖中，物件會遵照箭頭方向傳送訊息（message）給另一個物件，也因此而引發了接收訊息之物件的某一項操作（operation）。
換言之，在循序圖中的每一個訊息，都可以對應到物件所屬類別中已經定義好的操作。

正因如此，我們可以發現許多UML工具中，都有支援在循序圖中選用操作的功能。以StarUML為例，我們先新增了訂單類別，並且新增了五個操作，分別名為：取得日期、設定日期、取得金額、設定金額和計算金額，如圖9所示。

圖9：訂單類別


接著，我們在循序圖中新增一個訂單物件，並且發送訊息給這個訂單物件，如圖10所示。這時，我們可以按下名稱輸入框最左邊的「等號」按鈕，叫出如圖11的操作挑選視窗。最後，在我們點選了「計算金額」操作之後，可以發現訊息名稱已經自動被設定成「計算金額」了，如圖12所示。

圖10：新增訊息


圖11：挑選操作


圖12：計算金額


要點5如果你不知該如何動手開始繪製循序圖，很可能是你沒將使用案例敘述寫對，亦或是沒有完成穩健分析。（If you’re having trouble getting a sequence diagram started, you probably wrote the use case incorrectly and/ or didn’t complete robustness analysis.）

在我的實務經驗中，通常到了需要繪製循序圖時，就能夠檢驗出系統分析師的使用案例敘述寫得好不好了。

要點6經由探究系統的動態行為，你會得知靜態模式中的類別，需要哪些屬性與操作。（By exploring the dynamic behavior of the system, you learn which attributes and operations are needed in the classes contained within your static model.）

要點7記得，循序圖是決定物件行為的主要工具。你可以使用循序圖來配置操作給類別。（Remember that the sequence diagram is the primary vehicle for making behvior allocation decisions. You’re really using your sequence diagrams to assign operations to your classes as you go.）

類別圖通常不是一次就能夠繪製完全，而是透過一個又一個的使用案例，以及一張又一張的循序圖，經過多次循環更新的歷程之後，類別圖才會逐步地完善。

總之，循序圖與類別圖之間關係密切，主要有下列關聯：
1. 物件與類別—循序圖所列出的一群物件，都必須依據類別圖中的類別定義所產出。

2. 連結與關係—循序圖中的物件之間隱藏著連結（link），因為物件之間有連結，才能呼叫彼此的操作。而物件之間的連結，則必須依據類別之間的結合、聚合、組合或者依賴關係定義而產生。

3. 訊息與操作—循序圖中的物件能夠呼叫自身的操作，或者呼叫其他物件的操作，而這些操作都必須定義在類別圖的類別裡。

要點8在細部設計中，你將增添設計物件到領域物件中，譬如穩健圖中的邊界物件。（You are adding solution space objects to the problem domain objects as you explore system usage at a detailed level. Solution space objects include boundary （interface） objects from the robustness diagrams.）

要點9此時，你可以將許多設計物件考慮進來。在繪製循序圖時，在是在進行物件導向設計，所以設計樣式在此時會有很大的幫助。（You incorporate infrastructure, scaffolding, and helper objects into your designs at this point. Design patterns are often helpful here; this is where much of real OOD takes place.）

原著作者將循序圖定位成細部設計的產出，所以才會提到在此時可以使用設計樣式（Design Pattern）。

要點10使用案例敘述可以放置在循序圖中，便於從設計反向追蹤到使用者需求。（Writing the original requirements-level text for the use case in the margin of the sequence diagram provides visual requirements traceability from the design back to your user-certified requirements.）

在循序圖面上，可以於最左方放置使用案例敘述，不僅有助於理解與溝通，同時也方便從設計反向追蹤到使用者需求，如圖13所示。

圖13：使用案例敘述


除了循序圖以外，通訊圖也和循序圖一樣，適合用來表達一群物件之間的互動情況，下一期將會開始介紹通訊圖，以及染上分析癱瘓症時的十種現象。

作者簡介：
邱郁惠
研究OOAD、UML、MDA十餘年，經歷過顧問、專案、教學及寫作工作。離職後創辦UML Blog推廣UML，組織《UML互助會》社群定期舉辦軟體技術講座，出版多本UML專業書籍與電子書。目前擁有OCUP/UML三級認證、PMP認證。