第十三章作業行為塑模

第十三章作業行為塑模

導論 • 在物件導向系統發展過程中，完成了使用個案（或稱需求）塑模後，接下來便可進行物件資料結構塑模、物件互動行為塑模、作業行為塑模等活動，以開始架構系統。 • 一般的說法：Behavior Modeling • 作業行為塑模主要表達工具 • 狀態圖：State Machine Diagram (UML 2.x) • StateChart Diagram (UML 1.x) • 活動圖：Activity Diagram

導論（續1） • 作業行為塑模應該用狀態圖或活動圖或兩者皆用？這問題並無標準答案，應視系統之複雜程度、專案需求、系統分析師之習慣等因素來決定。如前所述，物件導向的分析與設計很難一次就完整的完成，常須經歷反覆的設計，才能漸趨完整或完美，因此作業行為塑模亦須反覆進行，才能有較滿意的成果。

狀態圖 • 狀態圖是一種塑模工具，它可用於表達一個物件、一個使用個案、多個使用個案間或一個系統在其生命週期中之所有狀態及其轉換關係。(???) • A statechart diagram shows a state machine. A state machine is a behavior that specifies the sequences of states an object goes through during its lifetime in response to events, together with its responses to those events. (User’s guide) • Some objects are incredibly complicated, so complex that developers can have difficulty understanding them. To understand complex classes better, particularly those that act in different manners depending on their state, you should develop one or more UML 2 state machine diagrams … describing how their instances work. … UML state machine diagrams depict the various states that an object may be in and the transitions between those states. (Agile Modeling)

狀態圖的元件 • 狀態圖之主要元件包括狀態與轉換，其運作規則是當轉換發生後，物件（或系統）會從某一狀態（稱為來源狀態），進入另一個狀態（稱為目的狀態），如圖13-1。 • 專題的要求： • 請針對你的專題找出至少一個比較複雜的物件，並劃出它的狀態圖。 • Objects that must respond to signals, which are asynchronous stimuli communicated between objects. Ex. Cellular phone must respond to random phone calls, keypad events, and to events from the network • Objects whose current behavior depends on their post behavior. Ex. The behavior of an air-to-air missile guidance system will depend on its current state, such as NotFlying (it’s not a good idea to launch a missile while it’s attached to an aircraft that’s still sitting on the ground) or Searching (you shouldn’t arm the missile until you have a good idea what it’s going to hit).

轉換 (Event[Guard]/Action) 來源狀態目的狀態圖13-1 狀態與轉換樣板

狀態圖的元件（續） • 基本元件 • States • Events • Transitions • 一個狀態是一個物件在其生命週期中，某一時間點之一個條件或情況，在此狀態中，它滿足某條件，執行某活動或等待某事件。 • A state is a condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some event.

狀態圖的元件（續） • 一個狀態有許多部分： • 名稱：名稱以字串命名，且名稱應是唯一（a state may be anonymous, meaning that it has no name） • 進入／離開之動作：actions executed on entering and exiting the state • Ex. entry / setMode(onTrack) • Ex. exit / setMode(offTrack) • 活動 (Activities)：When an object is in a state, it generally sits idle, waiting for an event to occur. Sometimes, however, you may wish to model an ongoing activity. • Ex. do / followTarget: followTarget is the name of another state machine. • Ex. do / op1(a); op2(b);op3(c); (a sequence of actions) • actions are not interruptible, but sequence of actions are.

狀態圖的元件（續） • 一個狀態有許多部分： • Internal transitions: transitions that are handled without causing a change in state. • Ex. newTarget / tracker.Acquire() • newTarget is an event. entry and exit actions will NOT be performed. • Deferred events：a list of events that are not handled in that state but, rather, are postponed and queued for handling by the object in another state • Ex. selfTest / defer • selfTest 是一個 event，會被延後至下一個狀態才執行，而對執行的那個狀態而言，這個事件就像剛剛發生的一樣。 • 比較少用

狀態圖的元件（續） • 一個狀態有許多部分： • A simple state is a state that has no substructure. • A state that has substates – nested states – is called a composite state. • 子狀態（substates） • disjoint（sequential） • concurrent（orthogonal）

狀態圖的元件（續） • 轉換是觸發物件（或系統）從一狀態進入另一狀態的事件、成立條件或動作。 • Source state: the stated affected by the transition; if an object is in the source state, an outgoing transition may fire when the object receives the trigger event of the transition and if the guard condition, if any, is satisfied • Event trigger • Guard condition: a boolean expression that is evaluated when the transition is triggered by the reception of the event trigger. • Action: an executable atomic computation that may directly act on the object that owns the state machine, and indirectly on other objects that are visible to the object. • Target state

狀態圖的元件（續） • Event Trigger • An event is the specification of a significant occurrence that has a location in time and space. • Events may include signals, calls, the passing of time, or a change in state. • A signal represents a named object that is dispatched (thrown) asynchronously by one object and then received (caught) by another. Ex. Exceptions. Modeled as <<signal>> and <<send>> • Transition • It is also possible to have a triggerless transition, represented by a transition with no event trigger. A triggerless transition – also called a completion transition – is triggered implicitly when its source state has completed its activity. • Ex. After (2 seconds) / send c.isActive  time event / send signal • Self-transition: source and target states are the same.

H … … 2 E D 3 4 圖13-2 狀態圖的元件與表達符號

Example: Vending Machine

Example: ATM Log In

開始動作／取第一個項目 [所有項目已檢查且所有發送檢查 do／檢查項目項目都存在] 活動／啟始運送轉換 [ 所有項目事件取消已檢查且某些項目不在收到項目[所有運送倉庫] 項目都存在] 取消狀態條件等待取消收到項目[某些取消項目不在倉庫] 已運送自身轉換結束圖13-3 狀態圖範例 • 訂貨處理狀態圖範例 [並非所有項目已檢查]／取下一個項目

狀態圖的元件（續2） • 採用 UML Distilled 的範例 • 訂貨處理範例有七個狀態，分別為開始、檢查、發送、等待、取消、已送貨與結束，狀態間之轉換與運作規則如下： • 開始狀態，先取第一個項目（動作）。 • 檢查狀態 • 做檢查（活動），若所有庫存項目尚未檢查完（條件），則需繼續取下一個項目（動作），並做檢查（活動），直到所有項目檢查完為止（重複迴圈；自身轉換）。

狀態圖的元件（續3） • 做檢查（活動），若所有項目均已檢查完，且所有項目均在倉庫（條件），則轉換到發送狀態。 • 做檢查（活動），若所有項目均已檢查完，且有某些項目不在倉庫（條件），則轉換到等待狀態。 • 等待狀態 • 收到項目（事件），若所有項目均在倉庫（條件），則轉換到發送狀態。 • 收到項目（事件），若有某些項目不在倉庫（條件），則轉換到等待狀態（重複迴圈；自身轉換）。

狀態圖的元件（續4） • 發送狀態，啟動送貨（活動），送貨（動作），完成後轉換至已送貨狀態。 • 系統在送貨前之任一狀態（例如檢查、發送、等待狀態），可允許隨時取消訂單（動作），而轉換到取消狀態。 • 系統在取消及已送貨狀態會馬上自動轉換至結束狀態。

超狀態 • 超狀態（Superstate） • 例如在已運送狀態之前，我們想要在任何時刻取消訂單，則可從檢查、等待、發送等狀態分別轉換至取消狀態。除了從各狀態直接使用轉換至取消狀態外，我們也可以將檢查、等待、發送狀態群集成一個超狀態，再由該超狀態轉換至取消狀態來表現。這兩種方式均可表達相同的資訊，但超狀態之應用可讓整個狀態圖較為清楚與單純。

開始超狀態的名稱 Active 檢查發送／檢查項目／啟始運送運送等待取消已運送結束圖13-4 超狀態圖範例

狀態圖之建構步驟與原則 • 狀態圖之建構步驟 • 找出狀態 • 找出狀態間之轉換 • 繪製狀態圖 • 精練狀態圖 • 建構狀態圖可參考下列原則︰ • 從循序圖中類別物件之操作描述、使用個案之描述，逐一找出狀態圖之狀態與轉換。 • 狀態之轉換，「事件 [成立條件]／動作」，此三個部分是可選擇性的，不一定要同時都具備。

狀態圖之建構步驟與原則（續） • 由狀態圖之上方或左上方以「開始」畫起，從系統的觀點，依類別物件之行為，將物件生命週期的活動狀態順序，逐一畫出所有狀態及轉換。 • 自身轉換的表示法是，箭頭由該狀態伸出，繞一圓弧後，箭頭再指向該狀態，並在適當位置說明「事件 [成立條件]／動作」。 • 繪製狀態圖時，其轉換符號應盡量避免交叉。

Example: Concurrent State • 訂單以及付款的動作可以同時進行 • 付款的狀態圖

Example: Concurrent State • 訂單以及付款的動作可以同時進行

History State • 歷史狀態 • Used with composite states (or superstates which contains substates) • Unless otherwise specified, when a transition enters a composite state, the action of the nested state machine starts over again at its initial state. However, there are times you’d like to model an object so that it remembers the last substate that was active prior to leaving the composite state.

Example: Booking • 不論狀態為何，若執行 selectBooking 但是找不到 booking，都會回到原先的狀態

Example: Booking

活動圖 • 活動圖被用於表達一個系統的流程（workflow） • 常被用於： • analyzing a use case by describing what actions need to take place and when they should occur; • describing a complicated sequential algorithm • modeling applications with parallel processes (or threads). • 活動圖可以表達物件或系統之活動、資訊流與控制等，因此可以把活動圖視為是流程圖、資料流程圖之擴充，因為活動圖除了能表達流程圖與資料流程圖之資訊外，還可以表達同步之行為。

活動圖 • You can think of an activity diagram as an interaction diagram turned inside out • An interaction diagram looks at the objects that pass messages • An activity diagram looks at the operations that are passed among objects.

活動圖之元件 • 活動圖之主要元件：活動與轉換，兩者之關係與表達如圖13-6。轉換活動活動 A B

活動圖之元件（續） • Activity diagrams commonly contain • Activity states and action states • Transitions • Objects • 每一項 operation 以一個 state 代表： • 開始（start state）：以一實心圓形表示。 • 結束（stop state）：以一實心圓形外加一空心圓圈表示。 • 活動：是真實世界的一個動作處理、一組動作程序或是可執行的一段副程式。活動以一圓角矩形表示，內部表達名稱或其他行為描述。 • Action states: cannot be decomposed further, represent an action • Activity states: can be further decomposed • There’s no notational distinction between action and activities states, except that an activity state may have additional parts such as entry and exit actions.

活動圖之元件（續1） • 轉換（Transitions） • 當一個動作或活動完成時直接到下一個活動的控制（也就是之前的 triggerless transition） • 轉換只有成立條件的控制，以一「箭頭」旁註明 [成立條件] 來表示。 • 分支（Branch） • 分支是用於表達當轉換發生後，有多個選擇路徑，但僅能依條件選擇其中一個路徑執行之。分支之表達符號是以一菱形，外加一條流入菱形之箭頭與多條流出菱形之箭頭表示。

活動圖之元件（續2） • 分岔（Fork） • 分岔是用於表達當轉換發生後，有兩個或兩個以上之平行活動發生的情況。分岔之表達符號是以一橫向黑實線條，外加多條流入之垂直箭頭與一條流出之垂直箭頭表示。 • 結合（Join） • 結合是用於表達平行活動結束之情況，表達符號與分岔類似是以一橫向黑實線條，外加一條流入之垂直箭頭與多條流出之垂直箭頭表示。 • 一定跟 Fork 成雙成對使用

活動圖之元件（續3） • 合併（Merge） • 合併是用於表達有多個路徑匯集於某點，之後再往下一個路徑執行。合併之表達符號與分支相似，是以一菱形外加多條流入菱形之箭頭與一條流出菱形之箭頭表示。 • Merge vs. Join？ • 責任區（Partitions or Swimlanes） • 責任區是用於表達活動圖中，哪些活動是由誰、哪個部門、類別或元件負責的一種方式，其表示方式就如同游泳池的水道一樣，每一水道代表一個負責的人、部門、類別或元件。 • Each swimlane has a name unique within its diagram. • A swimlane really has no deep semantics, except that it may represent some real-world entity (often organizational unit) • Each swimlane may eventually be implemented by one or more classes. • Every activity belongs to exactly one swimlane, but transitions may cross lanes.

圖13-7 活動圖之元件與符號表達

Example

活動圖之建構步驟與原則 • 活動圖之建構步驟與狀態圖一樣，包括： • 找出活動，必要時也需找出執行該活動之實體 • 找出活動間之轉換 • 繪製活動圖 • 精練活動圖 • 建構活動圖可參考下列原則： • 從使用個案描述或類別之操作描述中，找出相關的活動與轉換。

活動圖之建構步驟與原則（續） • 由活動圖之上方或左上方以「開始」畫起，接著依物件之操作、行為或系統之作業流程等活動發生之順序畫出活動及其間之轉換，而在最後的活動之後以「結束」表達之。 • 遇到有平行處理或多執行緒的活動時以分岔描述之，此時在分岔之前會有一個進入轉換，在分岔之後會有數個離開轉換。 • 有分岔就必須有結合，在所有分岔出去的平行處理之活動都執行完畢後需有結合。此時在結合之前會有數個進入轉換，在結合之後會有一個離開轉換。

活動圖之建構步驟與原則（續1） • 遇到數個有 [成立條件] 的擇一執行後續活動時以分支來表達，此時在分支之前會有一個進入轉換，在分支之後會有數個具有互斥條件的離開轉換。 • 合併用來描述以分支為開端的條件式活動的結束，此時在合併之前會有數個輸入轉換，在合併之後會有一個輸出轉換。 • 可以用責任區方式表達哪些活動是由誰、哪個部門、類別或元件負責，並將這些活動放置於同一「水道」內。

活動圖之建構案例 • 本節以西子灣公司訂購系統為例，依上述步驟進行作業行為塑模，並以活動圖先表達使用個案間之執行流程，也就是訂購作業之整體流程，再逐一表達每一個使用個案內之活動及其執行順序。 • 訂購系統整體流程 • 找出活動：依據使用個案圖裡的使用個案描述，暸解有哪些活動、轉換與執行程序等。由以上步驟得知訂購作業共有新增訂購項目、修改訂購數量、確認採購訂單、刪除訂購項目，及取消採購訂單等五個活動狀態。

活動圖之建構案例（續） • 找出活動間之轉換：西子灣公司訂購系統案例之整體作業流程如下： • 客戶在網站上瀏覽書籍產品型錄，並點選欲購買的書籍進行新增訂購項目的動作。 • 未進行下一個動作之前可重複新增訂購項目的動作繼續訂購書籍。 • 新增訂購項目結束後，客戶先決定下一個步驟為何？若要結束訂購進行結帳則進入確認採購訂單；若要修改書籍訂購數量則進入修改訂購數量；若要刪除某本書籍則進入刪除訂購項目；若要放棄本次訂購則進入取消採購訂單。

活動圖之建構案例（續1） • 修改訂購數量後繼續進行新增訂購項目的動作。 • 刪除訂購項目結束後，客戶先決定下一個步驟為何？若要結束訂購進行結帳則進入確認採購訂單；若要繼續訂購書籍則進入新增訂購項目，如果訂購項目全數刪除則進入取消採購訂單。 • 執行取消採購訂單動作時，系統進入刪除訂購項目，如果訂購項目全數刪除則回到取消採購訂單，並結束線上訂購的工作。 • 確認採購訂單完成後則結束線上訂購的工作。

活動圖之建構案例（續2） • 繪製活動圖 • 依上述步驟所找出之活動與活動間之轉換，西子灣公司訂購系統案例之整體作業可以活動圖表達，如圖13-9。

繼續訂購書籍(??) 客戶上網訂購書籍新增訂購項目繼續訂購書籍確認採購訂單修改訂購項目 [結束訂購進行結帳] [決定修改訂購數量] [決定刪除某本書籍] [決定放棄本次訂購] 刪除訂購項目取消訂購項目執行取消訂單 [確認訂單] [採購項目全數刪除完成] [決定繼續訂購書籍] 圖13-9 西子灣公司訂購系統案例之活動圖最好一個use case，一個activity diagram。 No input, 3 outputs

活動圖之建構案例（續3） • 新增訂購項目使用個案 • 找出活動：依據新增訂購項目使用個案的描述，分析有哪些活動、轉換、執行程序與參與之實體等。結果得知共有顯示細部說明、新增訂購項目、設定訂購數量、計算購物車總金額等四個活動，其中有客戶、書籍產品型錄、購物車等三個實體參與。客戶為起始者，顯示細部說明之活動屬於書籍產品型錄，而其他活動屬於購物車。

活動圖之建構案例（續4） • 找出活動間之轉換：西子灣公司訂購系統案例之新增訂購項目使用個案作業流程如下： • 客戶在網站上瀏覽書籍產品型錄，點選顯示細部說明。 • 新增欲訂購的書籍產品，購物車上會增加此項書籍產品，數量以預設值1計之。 • 設定欲訂購的數量，購物車上會修改該項書籍產品的數量。 • 系統自動計算目前購物車內書籍產品的總金額。

活動圖之建構案例（續5） • 繼續訂購則回到書籍產品型錄繼續瀏覽，否則結束新增訂購項目。 • 繪製活動圖：依上述步驟所找出之活動與活動間之轉換，西子灣公司訂購系統案例之新增訂購項目使用個案可以活動圖表達，如圖13-10。

顯示細部說明 新增訂購項目設定訂購項目計算購物車總金額是否訂購完畢（否）（是）圖13-10 新增訂購項目使用個案之活動圖

第十三章作業行為塑模