7-1 互 動 7-2 順序圖 7-3 合作圖 7-4 順序圖的個案說明 7-5 合作圖的個案說明

Presentation on theme: "7-1 互 動 7-2 順序圖 7-3 合作圖 7-4 順序圖的個案說明 7-5 合作圖的個案說明"— Presentation transcript:

1 7-1 互 動 7-2 順序圖 7-3 合作圖 7-4 順序圖的個案說明 7-5 合作圖的個案說明
順序圖與合作圖 大 綱 7-1　互　動 7-2　順序圖 7-3　合作圖 7-4　順序圖的個案說明 7-5　合作圖的個案說明

2 7-1 互動圖的基礎-說明 互動圖（Interaction Diagrams）如同其名是用來描述模型中不同元素之間的互動，即描述系統的動態行為，可以清楚呈現系統與使用者操作之間的互動；一組物件之間如何使用訊息互動來合作完成指定的行為。 互動圖可以用來呈現4+1觀點軟體系統模型的邏輯觀點，如下圖所示：

3 7-1 互動圖的基礎-種類 循序圖（Sequence Diagrams）：使用時間軸方式描述物件之間的互動，強調物件之間訊息傳遞的時間順序。
通訊圖（Communication Diagrams）：描述物件的互動，強調物件之間的關係、訊息流向和控制流程，在1.x版稱為合作圖（Collaboration Diagrams）。 時序圖（Timing Diagrams）：UML 2.0版支援的圖形，描述詳細的時間資訊，互動元素之間的條件資訊和狀態改變。 互動概觀圖（Interaction Overview Diagrams）：UML 2.0版支援的圖形，使用循序、通訊和時序圖以高階方式描述系統發生的重要互動。

4 7-1 互動圖的基礎-目的 互動圖的主要目的是使用視覺化方式顯示系統的互動行為，因為視覺化顯示互動是一件困難的工作，所以我們需要建立不同觀點的互動圖來描述系統的行為。基本上，互動圖的主要目的為： 捕捉系統的動態行為。 描述系統物件之間的訊息流程。 描述系統物件的結構化組織。 描述一組物件之間訊息傳遞的互動。

5 7-2 循序圖 循序圖的基本符號 循序圖的訊息 框架 複雜互動的互動片斷

6 7-2 循序圖-說明 循序圖（Sequence Diagram）是使用時間軸來描述物件之間的互動，強調物件之間訊息傳遞的時間順序，請注意是時間順序，而不是花費的時間，關於花費時間部分可以使用時序圖來描述。 在循序圖的垂直軸是時間，可以顯示時間順序的訊息傳送；水平軸是隨著訊息傳送，從一個參與者物件旅行至另一個參與者物件的互動過程。

7 7-2 循序圖-範例 例如：圖書銷售系統（Book Sales System）產生圖書銷售報表的循序圖，如下圖所示：

8 7-2-1 循序圖的基本符號-參與者 參與者（Participants）簡單的說就是物件，它是使用方框表示，也可以使用演員符號，參與者是位在循序圖上方且從左至右依序排列，在方框中是參與者名稱，其基本語法如下所示： 名稱:類別名稱 上述語法的「:」分號前是物件名稱；之後是類別名稱，如下圖所示：

9 7-2-1 循序圖的基本符號-時間與生命線 在參與者下方垂直的虛線稱為「生命線」（Lifeline），代表互動發生順序的時間軸，時間是由上而下增加，如右圖所示： 控制焦點表示在一段時間中，該物件直接透過某個程序或著經由某個程序執行某個動作，在圖形中以一個小長方形表示。在小長方形的頂端正對著動作的開始點，底端則對應到該動作的完成點。

10 7-2-1 循序圖的基本符號-訊息(說明) 訊息（Messages）是從來源參與者（或稱送出參與者）的生命線送到目的參與者（或稱接收參與者）的生命線，可以讓接收訊息的參與者進入啟動棒來執行所需操作，如下圖所示：

11 7-2-1 循序圖的基本符號-訊息(種類) 在循序圖的訊息可以分為兩種，如下所示：
同步訊息（Synchronous Messages）：當參與者送出同步訊息，必須等到回應後才會繼續執行，同步訊息是使用實心三角形箭頭線來表示，例如：上述循序圖的第1個訊息和前述gen:報表產生器物件送給report:圖書報表物件的setCreateDate()就是同步訊息。 非同步訊息（Asynchronous Messages）：參與者送出非同步訊息，並不需要等到回應就可以繼續執行。非同步訊息是使用箭頭來表示，例如：上述循序圖的第2個訊息。

12 7-2-1 循序圖的基本符號-訊息(語法) 傳回值 = 訊息名稱(參數列) : 傳回型態 循序圖的訊息基本語法，如下所示：
上述訊息語法依序是傳回值、訊息名稱（通常是類別的方法名稱）、參數列和傳回型態。一些訊息的範例，如下所示： 送出訂單() setCreateDate(date) d = getReportDescription(id) d = getReportDescription(id) : ReportDescription

13 7-2-2 循序圖的訊息-呼叫訊息 呼叫訊息（Call Message）是循序圖最常用的訊息，它是呼叫目標參與者的操作，例如：客人（Customer）在自動販賣機面板投錢操作的循序圖，如下圖所示：

14 7-2-2 循序圖的訊息-回傳訊息 回傳訊息是表示呼叫訊息的傳回值，一般來說，它並非必須符號，因為可以使用啟動棒結束來隱含代表。循序圖的回傳訊息是使用虛線→表示呼叫訊息的操作結束，在上方是傳回值的描述。 例如：客戶在自動販賣機的面板投錢後，操作面板送出檢查金額()訊息至記錄器物件，可以傳回可選擇產品的清單，如下圖所示：

15 7-2-2 循序圖的訊息-巢狀訊息 巢狀訊息（Nested Message）就是當呼叫訊息送至目的參與者後，就會進一步觸發目的參與者送出更多的訊息，這些訊息稱為原觸發訊息的巢狀訊息。 例如：當客戶在自動販賣機的面板投錢後，在操作面板可以顯示可購買的產品，以便讓客戶選擇購買的產品，如下圖所示：

16 7-2-2 循序圖的訊息-自身訊息 自身訊息（Self Message）就是送出呼叫訊息給自己，以Java語言來說，就是呼叫同一個物件的方法（通常是一些宣告成private的工具方法）。例如：旅館aHotel物件送出自身訊息檢查指定日期是否有空房間，如右圖所示：

17 7-2-2 循序圖的訊息-遞迴訊息 訊息還可以遞迴將訊息傳送至物件自己的同一個操作，稱為遞迴訊息（Recursion Messages）。例如：計算階層N!的Factorial物件f，如右圖所示：

18 7-2-2 循序圖的訊息-產生訊息與消滅訊息 在循序圖的物件可以送出產生訊息<<create>>建立其他實例（Instances）；或送出消滅訊息<<destroy>>表示物件生命周期的結束。例如：從購物車新增和刪除訂單項目的循序圖，如下圖所示：

19 7-2-3 框架 UML 2.x版的框架（Frame）提供UML圖形一個圖形邊界，它是一個大型的長方形框，在框架左上角顯示框架名稱，實際UML圖形是位在長方形框的範圍之內，如下圖所示：

20 7-3　合作圖 合作圖所強調的是參與互動的物件組織，在繪製合作圖時，我們先將參與互動的物件當作節點放置在圖上，再繪製連線將各個節點物件連在一起，最後再把每一個物件所傳送與接收的訊息標示上去，即可完成一個可以看出在物件結構組織內容中的控制流程。

21 合作圖中也有二個很重要的特點─路徑(path)與序號(sequence number)，路徑顯示了物件與物件間的連接關係，我們可以在連線的遠端加上一個可以表示路徑的模板型別，一般常用的路徑有local、parameter、global及self等。

22 序號則是為了能顯示訊息的時間順序，我們可以在訊息的旁邊標示號碼，這個號碼從1開始遞增，也就是說新的控制流程訊息出現時，則是依序由2、3…繼續增加。

23 為了能顯示細部的訊息順序，必要時也可以採用巢狀表示法，一般在顯示巢狀訊息時，大都採用杜威表示法(Dewey decimal numbering)，杜威表示法是以1代表第一個同步訊息，1.1表示第一個訊息的第一個巢狀訊息，1.2表示第一個訊息的第二個巢狀訊息，依此類推，1.x表示第一個訊息的第x個巢狀訊息。在合作圖中，巢狀訊息的深度是不受限制的，完全視系統開發者的需要而定，在一個連線中也可以有多個訊息，但是這些訊息的序號必須是唯一的。

24 在一個正常的系統中，各個物件間的關係並不都是用循序控制(sequence control)的流程就可以表達的，有時候我們會需要以反覆(iteration)或者分歧(branching)的方式來表示較為複雜的控制流程。

25 反覆的控制流程代表一組重複執行的訊息，在繪製反覆控制流程時，可以在訊息的序號前加上一個簡單的反覆表示式(iteration expression)，如i:= 1..n表示該項訊息要執行n次，有了這個反覆表示式，反覆控制流程就會依表示式所給的訊息反覆執行。

26 在實體的世界中，有些物件的發生是具有條件性的，亦即在某種條件之下才會發生某種特定的行為，在UML的塑模過程中我們可以在訊息上加上條件式來表示之，條件式表示該訊息會根據某一個布林條件式來執行。在塑造條件式時，可以在訊息的序號前加上一個條件子句，如在學生的成績單中我們希望成績小於60分時，學生的成績以紅色表示，我們可以在顯示成績的訊息上加上 score<60 的條件式，當條件成立時，則成績以紅色表示。

27 圖7-4合作圖的例子係由圖7-1的順序圖所衍生而來，由圖7-3中可以看出「客戶端」物件先建立(create)屬於local的「交易」物件，再以setAction()的操作將相關參數由「客戶端」物件傳送給「交易」物件，接下來是以杜威表示法顯示一個巢狀結構：「交易」物件先後以setValues()操作分別將不同的參數d、a值，傳送給屬於global的「ODBC代理主機」物件，最後在完成參數傳遞後，由「客戶端」物件將「交易」物件銷毀。

28 圖7-4　合作圖

29 在7-1節中曾經提到順序圖與合作圖二者之間是可以互相轉換的，也就是說我們可以先畫出順序圖，再由這個順序圖轉換出其相對應的合作圖，也可以先畫出合作圖，再從這個合作圖畫出相對應的順序圖，而且在這樣的一個轉換過程中，不會造成資訊的遺失。

30 由上述這一段話及圖7-1及圖7-4我們可以看出順序圖與互動圖語意(semantic)上是相等的，但是它們所表達的資訊卻是不完全一樣的，在合作圖中主要表示了物件的之間的連結方式，如「客戶端」物件與「交易」物件的連結是屬於local的，而「交易」物件與「ODBC代理主機」物件間的連結是屬於global的，物件間這樣的關係在順序圖中是沒有表達的。

31 同樣的，在順序圖中「客戶端」物件收到「交易」物件所傳送的完成(committed)訊息後，才發出訊息將「交易」物件銷毀，這樣的一個程序也沒有在合作圖中顯示出來。由此可以看出，順序圖與合作圖所描述的雖然是同一個模型，但是二者所顯示的資訊卻未必完全一致。

32 依物件組織塑造控制流程時，應該注意以下事項：
 不管所面對的是一個系統、子系統、類別、合作或者是使用案例的一種情境，都要先設定互動的內容。  先找出物件在互動中所扮演的角色，再設定互動的步驟。把這些物件放在合作圖中做為節點，重要的物件置於圖的中間，其他的物件則放在它的四週。  設定每一個物件的初始值。如果物件的屬性值、標記值(tagged value)、狀態或角色在互動的過程中，產生了重大的變化，應該複製一份在圖上並且更新它的值，這二個新、舊物件間以become或copy的模板型別訊息加以連接。

33  依所傳遞的訊息訂定物件的連線，先繪製物件間的結合關係連線，來表示物件間的結構連結，再繪製其他連線，並標示適當的模板型別(local或global)，訂出二物件間的關聯性。
 從發起互動的訊息開始，把每一個訊息放到適當的連線上，並設定其正確的序號，如果有巢狀序號則以杜威表示法標示。  如果要訂出時間與空間的限制，可以在每一個訊息上加上時間的符號，並標示出適當的時間、空間之限制標示。  如果需要訂出較正式的控制流，可以在每個訊息上附加條件式。

34 圖7-5是以物件的結構關係來描述學生註冊的控制流程，圖中共有五個物件─「註冊組」(RegistrarAgent)物件、「學生」(Student)物件、「學校」(School)物件及二個「課程」(Course c1 & c2)物件。物件間所有的互動是由「註冊組」物件建立一個新的「學生」物件開始，隨後「註冊組」物件以addStudent()操作在「學校」物件中新增一筆學生資料以後，就會以register()操作通知「學生」物件進行註冊。

35 圖7-5　依物件組織塑造控制流程

36 接下來是一連串的巢狀表示法，「學生」物件先呼叫自己的getSchedule()操作，接著把自己分別加入到二個「課程」物件中，最後，在「學生」物件將其註冊(Register)屬性值由False 改為True，完成註冊程序。

37 在圖7-5出現了二個「學生」物件，這樣的表示符合前面注意事項中所提到的：物件的屬性值、標記值(tagged value)、狀態或角色在互動的過程中，產生了重大的變化，應該複製一份在圖上並且更新它的值，這二個新、舊物件間以become或copy的模板型別訊息加以連接。

38 其次，在圖7-5中「學校」物件與二個「課程」物件間分別有一條連線，而且「學挍」物件與「學生」物件間也有一條連線，這三條連線雖然都沒有任何訊息，但是卻扮演了相當重要的角色。「學生」物件在呼叫getSchedule()操作時，透過「學校」物件才能間接找到了二個「課程」物件─c2、c2，再把自己加入「課程」物件中完成註冊手續。

39 合作圖的管理方式與順序圖類似，在一個簡單的系統中，我們可以用一個合作序圖來表示其控制流程，但是，一般而言，在系統開發的過程中，我們都會用多個合作圖來表示物件間的控制流程、路徑例外條件…等狀態。同樣的我們也可以利用類別庫來組織各個相關的合作圖，以方便日後的系統開發、維護與管理工作。

40 7-4　順序圖的個案說明 本章將利用在第6章中所介紹的案例，繼續往下延伸成順序圖及合作圖，本節首先介紹順序圖，在下節中再接續介紹合作圖。在第6章的案例中所要討論的標的是售票系統，而其他的系統（自動售票機、信用卡付費系統）或參與者（售票員、管理者）都是動作者，在這一節中我們先討論動作者與系統間之關係，再討論存在於系統中各物件間的順序關係。

41 一、自動售票機與售票系統之順序圖 圖7-6中表示的是自動售票機出售當場次門票之順序圖，繪製順序圖時，首先要確認參與互動的物件。在自動售票機出售當場次門票之事件中，除了我們要描述的售票系統外，參與的物件還有「自動售票機」物件及「信用卡付費系統」物件二個物件，在繪製順序圖時，我們先把它們依序放在圖的上方由左而右排列，在各物件下方則是表示在其生命週期中的各個行為。

42 圖7-6　自動售票機出售當場次門票之順序圖

43 購票者透過自動售票機上的人機介面購票時，「自動售票機」物件會先向售票系統查詢該場次目前所餘之空位數，售票系統會將該場次可出售的座位數回應給「自動售票機」物件。若該場次的比賽尚有空位，則可同意購票者購買該場次的門票，並將「自動售票機」物件中輸入的購買數量傳送至售票系統中，系統在計算當次購票的應付金額後，會將應付金額傳回「自動售票機」物件上的螢幕，讓購票者選擇以現金付款或是以信用卡付款。

44 如果購票者想要以信用卡付費，則可以將信用卡置於「自動售票機」物件上的讀卡設備中，「自動售票機」物件上的讀卡設備會將購票者的信用卡卡號等資料，傳至售票系統上，並且經由售票系統送至「信用卡付費系統」物件，「信用卡付費系統」物件會透過金融網路，將購票者的信用卡資料送至發卡銀行，在經過發卡銀行完成資料審核後取得本次交易之授權碼，同時將授權碼傳回至售票系統。

45 售票系統在收到「信用卡付費系統」物件所傳回的授權資料，即將列印門票的指令通知自動售票機，同時送出信用卡交易完成的訊息給「自動售票機」物件，並顯示完成交易的訊息於「自動售票機」物件的螢幕上，同時將交易憑證印出。

46 二、售票員出售當場次門票之順序圖 圖7-7中表示的是由售票窗口的售票員出售當場次門票之順序圖，同樣的，我們也是把參與的物件放在圖的上方，並且由左而右的排列。購票者透過現場的售票窗口購票時，售票員由位於售票口的終端機上之人機介面先查詢該場次目前所餘之空位數，售票系統會將該場次可出售的座位數回應至售票員所用之終端機。若該場次尚有空位，則可同意購票者購買，並將由售票員在終端機中輸入的購買數量傳送至售票系統中，系統在計算當次購票的應付金額後，會將應付金額傳回售票員的終端機上，購票者可以選擇以現金付款或是以信用卡付款。

47 圖7-7　售票員出售當場次門票之順序圖

48 如果購票者想要以信用卡付費，售票員可以將購票者的信用卡置於售票口的讀卡設備中，讀卡設備會將購票者的信用卡卡號等資料，傳至售票系統上，並且經由售票系統送至「信用卡付費系統」物件，「信用卡付費系統」物件會透過金融網路，將購票者的信用卡資料送至發卡銀行，在發卡銀行完成資料審核後，取得本次交易之授權碼，同時將授權碼傳回至售票系統。

49 售票系統在收到「信用卡付費系統」物件所傳回的授權資料，即將列印門票的指令通知位於售票口的印表機，同時送出信用卡交易完成之訊息至位於售票口之終端機螢幕上，並列印出本次交易之憑證。

50 三、售票員出售季票之順序圖 圖7-8中表示的是由售票員窗口出售當球季季票之順序圖，購票者僅能透過窗口向售票員購買球季中某種球隊對戰組合之季票，售票員由售票口的終端機上的人機介面先查詢該對戰組合場次的之空位數，售票系統會將該場次可出售的座位數回應給終端機。若該對戰組合場次尚有空位，則可同意購票者購買，並將由售票員在終端機中輸入的購買數量傳送至售票系統中，系統在計算當次購票的應付金額後，會將應付金額傳回售票口終端機的螢幕上，購票者可以選擇以現金付款或是以信用卡付款。

51 圖7-8　售票員出售季票之順序圖

52 如果購票者想要以信用卡付費，則可以將信用卡交給售票員，透過置於售票口的讀卡設備，會將購票者的信用卡卡號等資料，傳至售票系統上，並且經由售票系統送至「信用卡付費系統」物件，「信用卡付費系統」物件會透過金融網路，將購票者的資料送至發卡銀行，經發卡銀行審查資料後，取得本次交易之授權碼，同時將授權碼傳回至售票系統。

53 售票系統在收到「信用卡付費系統」物件所傳回的授權資料，即將列印門票的指令通知位於售票口的印表機，同時送出信用卡交易完成的訊息，並列印出本次交易之憑證。

54 四、系統出售當場次門票之順序圖 前面所敘述的是從系統的角度來表示動作者與系統間的順序關係，接下來我們要分析系統中各物件間的順序關係。

55 圖7-9中所示為購票者經由自動售票機或是透過售票口購買當場次門票時，售票系統中各物件間的順序圖。在繪製系統的順序圖前，首先要分析在購買當場次門票的情境中，有哪些物件會參與互動，經過分析後發現參與互動的物件計有「資料輸入、輸出介面」物件、「場次」物件及「計價」物件等三個物件，於是分別將其置於圖的上方，並且由左至右排列。

56 圖7-9　購買當場次門票售票系統之順序圖

57 「資料輸入、輸出介面」物件是售票系統與外界的溝通介面，自動售票機的購票資料可經由系統的「資料輸入、輸出介面」物件，進入系統中進行後續的處理，售票口的售票員也可以透過位於售票口的終端機上的使用者介面，將購票資料經由「資料輸入、輸出介面」物件進入系統中，以進行後續的處理。

58 「資料輸入、輸出介面」物件會將來自「自動售票機」物件或售票口的終端機之購票場次及數量資料送至「場次」物件，「場次」物件根據「資料輸入、輸出介面」物件所傳來的購票場次及數量資料，查詢該場次所餘之空位數，並將可售的座位數傳回「資料輸入、輸出介面」物件，俾利其將資料傳回「自動售票機」物件或位於售票口之終端機上的螢幕。

59 購票者如果是用自動售票機購票，則透過「自動售票機」物件上的螢幕，由購票者直接輸入購買數量，如果是在售票口向售票員購票，則是由售票員將購買數量輸入位於售票口的終端機，不論是由「自動售票機」物件輸入購買數量抑或是由售票口的終端機輸入購買數量，都會經由「資料輸入、輸出介面」物件將購買數量送到「場次」物件。

60 「場次」物件在收到購買數量後，立即將資料庫中該場次的座位數扣除，同時將購買數量送到「計價」物件。「計價」物件收到購買數量後，即根據內野與外野、全票與半票不同的票價計算該次交易的價格，並將計算出來的價格傳回至「資料輸入、輸出介面」物件，經由「資料輸入、輸出介面」物件將本次購票價格傳回「自動售票機」物件或位於售票口的終端機之螢幕上。

61 五、系統出售季票之順序圖 圖7-10所示則是購買當季季票之順序圖，由前一章中系統分析師至聯盟所做的訪談可知，購票者必須透過售票口才能購買當球季中各種對戰組合的季票，經過分析，在系統中訂出一個「資料輸入、輸出介面」物件，用於接受來自位於售票口的終端機上所傳來的球季對戰組合及購買數量，並將其資料傳送到「場次」物件。

62 圖7-10　購買季票之順序圖

63 「場次」物件在收到「資料輸入、輸出介面」物件所傳來的球季對戰組合及數量等資料後，立即先查詢在本球季中，該一對戰組合還有哪些場次所餘的數量足以滿足此次購票需求，並將所查詢的資料傳回「資料輸入、輸出介面」物件，由「資料輸入、輸出介面」物件把資料送回售票口的終端機螢幕上。

64 在售票員依購票者的需求將購買場次及數量在售票口的終端機螢幕上輸入後，透過系統的「資料輸入、輸出介面」物件把資料送到「場次」物件，「場次」物件會先依所收到的場次及數量等資料，把該場次的座位數扣除，同時把購票數量送到「計價」物件，由「計價」物件計算本次購票的票價，並把計算出來的票價傳回系統的「資料輸入、輸出介面」物件，由「資料輸入、輸出介面」物件將票價送回售票口終端機的螢幕上。

65 根據以上的討論，我們在購買季票的事件中訂出了三個物件─「資料輸入、輸出介面」物件、「場次」物件及「計價」物件，並將它們依序由左而右的排列在圖的上方，各物件於生命週期中所傳送與接收的訊息，則依序表示於各物件的下方。

66 六、信用卡付費之順序圖 在圖7-9及圖7-10中分別說明了購票者經由自動售票機或由售票口購買當場次門票時之順序圖，接下來要討論的是購票者若是以信用卡做為付款工具時，系統應如何運作。

67 購票者選擇以信用卡做為付款工具時，可以利用自動售票機上的讀卡設備讀入信用卡相關資料，也可以將信用卡交由售票口的售票員，利用位於售票口的讀卡設備讀入信用卡相關資料。

68 經過分析討論後，發現參與信用卡付費的物件有三個─「信用卡資料讀取設備」物件、「信用卡資料」物件及「輸入及輸出介面」物件，在繪製順序圖時，將這三個物件依序由左至右放在圖的上方，再逐一畫出其生命週期中所產生或交換的訊息，如圖7-11中所示。

69 圖7-11　購票者以信用卡付費之順序圖

70 在圖7-11中由「信用卡資料讀取設備」物件讀入購票者的信用卡資料後，系統立即將購票者的信用卡卡號及有效日期等資料傳至「信用卡資料」物件，「信用卡資料」物件會將「信用卡資料讀取設備」物件所傳來的信用卡卡號及有效日期等資料依SSL的方式加密後，透過「輸入及輸出介面」物件傳送至「信用卡付費系統」物件，由「信用卡付費系統」物件將資料送至發卡銀行進行驗證。

71 發卡銀行驗證購票人的信用卡資料無誤後，即傳回本次交易之授權碼，「信用卡付費系統」物件在收到發卡銀行送回之授權碼，會透過系統的「輸入及輸出介面」物件把本次交易之授權碼傳回給「信用卡資料」物件，「信用卡資料」物件在記錄本次交易之授權碼後，完成本次交易。

72 7-5　合作圖的個案說明 在上一節中已經分別的說明了利用自動售票機購買當場次門票的系統順序圖、經由售票員在售票口購買當場次門票的系統順序圖、在售票口透過售票員購買季票之系統順序圖及以購票者以信用卡付費之順序圖，在本節中將接著繼續說明這些行為之合作圖。

73 一、自動售票機與系統的合作圖 在本節中仍然是先由系統的角度來分析合作圖，再討論系統內部的合作關係。在進行分析時首先以售票系統為中心，先界定出系統外界的二個動作者─自動售票機及信用卡付費系統─與系統間的合作關係，再將三者間的訊息交換表示出來，並以數字表示事件發生的時間順序。

74 在圖7-12表示的是由自動售票機出售當場次門票時之合作圖，在圖中有三個物件─「自動售票機」物件、「售票系統」物件及「信用卡付費系統」物件。在繪圖時先在圖中的適當位置放置這三個物件，再把物件間的訊息傳遞依序寫在該連結旁邊。

75 圖7-12　自動售票機出售當場次門票之合作圖

76 由圖中可以看出「自動售票機」物件會先送出查詢該場次之空位數的訊息，在「售票系統」物件傳回該場次可出售的座位數後，「自動售票機」物件可讓購票者輸入欲購買之座位數，隨後並將購買數量傳至「售票系統」物件。

77 「售票系統」物件在收到由「自動售票機」物件傳來的購買數量訊息，在計算出應付金額後，將購票應付金額送至「自動售票機」物件，若購票者想要以信用卡付費，則可透過信用卡讀卡設備讀入信用卡資料，並將其資料由「自動售票機」物件傳至「售票系統」物件，購票者的信用卡資料經過系統的加密處理後，再經由「信用卡付費系統」物件至發卡銀行驗證，發卡銀行驗證購票者的信用卡資料後，會將本次購票交易之授權碼傳回。

78 發卡銀行的授權碼傳回後，「信用卡付費系統」物件會將授權碼傳回「售票系統」物件，「售票系統」物件接獲授權碼並記錄後，即會將印出門票的訊息傳送到「自動售票機」物件，以便列印門票，同時送出完成信用卡交易之訊息，並列印出本次交易之憑證。

79 二、售票員出售當場次門票之合作圖 製作售票員出售當場次門票之合作圖的概念與由自動售票機出售當場次門票之合作圖類似，首先也是以售票系統為中心，先界定出系統外界的二個動作者─售票員及信用卡付費系統─與系統間的合作關係，再將三者間的訊息交換表示出來，並以數字表示事件發生的時間順序。

80 圖7-13表示的是售票員在售票口出售當場次門票時之合作圖，在圖中有三個物件─「售票員」物件、「售票系統」物件及「信用卡付費系統」物件。在繪圖時先在圖中的適當位置放置這三個物件，再把物件間的訊息傳遞依序寫在該連結旁邊。

81 圖7-13　售票員出售當場次門票之合作圖

82 由圖中可以看出「售票員」物件會先透過位於售票口的終端機查詢該場次之空位數的訊息，在「售票系統」物件傳回該場次可出售的座位數後，「售票員」物件輸入購票者欲購買之座位數，並將購買數量傳至「售票系統」物件。

83 「售票系統」物件在收到由「售票員」物件輸入的購買數量訊息，在計算出應付金額後，將購票應付金額送至位於售票口的終端機螢幕上，若購票者想要以信用卡付費，則可將信用卡交由售票口的售票員，透過信用卡讀卡設備讀入信用卡資料，並將其資料傳至「售票系統」物件。

84 購票者的信用卡資料經過系統的加密處理後，再經由「信用卡付費系統」物件至發卡銀行驗證，發卡銀行驗證購票者的信用卡資料後，會將本次購票交易之授權碼傳回。

85 發卡銀行的授權碼傳回後，「信用卡付費系統」物件會將授權碼傳回「售票系統」物件，「售票系統」物件接獲授權碼並記錄後，即會將印出門票的訊息傳送到位於售票口的印表機，以便列印門票。同時亦送出完成信用卡交易之訊息，並列印出本次交易之憑證。

86 三、售票員出售季票的合作圖 在繪製出售季票的合作圖時，也是以「售票系統」物件為中心，再考量與其有訊息傳送之的物件─「售票員」物件及「信用卡付費系統」物件，在繪圖時先在圖中的適當位置放置這三個物件，再把物件間的訊息傳遞依序寫在該連結旁邊。

87 由於整個球季中的賽事有多種球隊的對戰組合，如牛─象、獅─鯨…等，考慮球迷有特定的支持對象，所以允許球迷在購票時可以選擇其所支持的球隊，因此，售票員在出售球季季票時，必須要先查詢特定的對戰組合場次是否還有餘位及餘位數。

88 在系統回應了各場次可出售的座位數後，售票員即可輸入購票者所欲購買的場次與數量，系統在計算完本次購票所需支付的票價後，會將本次購票應付金額傳回位於售票口的終端機螢幕上。

89 圖7-14　售票員出售季票之合作圖

90 若購票者想要以信用卡付費，則可將信用卡交由售票口的售票員，透過信用卡讀卡設備讀入信用卡資料，並將其資料傳至「售票系統」物件。購票者的信用卡資料經過系統的加密處理後，再經由「信用卡付費系統」物件至發卡銀行驗證，發卡銀行驗證購票者的信用卡資料後，會將本次購票交易之授權碼傳回。

91 發卡銀行的授權碼傳回後，「信用卡付費系統」物件會將授權碼傳回「售票系統」物件，「售票系統」物件接獲授權碼並記錄後，即會將印出門票的訊息傳送到位於售票口的印表機，以便列印門票。同時亦送出完成信用卡交易的訊息，並列印出本次交易之憑證。

92 四、系統出售當場次門票之合作圖 以上的幾個合作圖可以讓系統開發的人員很快的了解到系統與外界動作者之間的關係，接著我們再來分析系統內部應該要如何運作才能滿足需求，在本小節先探討系統出售當場次門票時，系統內部各個物件間有哪些合作關係。

93 在探討物件間的合作關係前，首先要了解到在出售門票的事件中到底會有哪些物件參與互動，經過分析後計有一個資料庫─場次座位資料庫─與三個物件─「資料輸入、輸出介面」物件、「場次」物件及「計價」物件，參與出售當場次門票的作業。

94 不論購票者是由自動售票機購票或者是在售票口透過售票員購票，其購票資料都是透過「資料輸入、輸出介面」物件進入售票系統中，而系統所回應的資料也是透過「資料輸入、輸出介面」物件傳到自動售票機是位於售票口的終端機，所以，「資料輸入、輸出介面」物件可說是系統與外界環境的窗口。

95 購票場次及數量資料透過「資料輸入、輸出介面」物件進入售票系統，「場次」物件先根據所欲購票的場次，到場次座位資料庫中查詢目前該場次的餘位數，並將所查詢到的餘位數傳回「資料輸入、輸出介面」物件。

96 在確認購票數量後，再經由「資料輸入、輪出介面」物件將購買數量傳給系統中的「場次」物件，「場次」物件在收到本次購票數量必須同步進行二件工作，在圖中以杜威表示法表示這二個巢狀訊息，首先是要把場次座位資料庫中的該場次座位數減少，這個作業表示在標示為6.1的訊息上，同時，要把訂票數量的資料送給「計價」物件，以便系統能計算本次購票的價格，這個作業表示在標示為6.2的訊息上。

97 「計價」物件根據由「場次」物件所傳來的訂票數量資料，計算本次購票的金額，並將計算出的結果透過「資料輸入、輸出介面」物件傳回自動售票機或位於售票口的終端機螢幕。聰明的讀者你可能會發現，為什麼圖7-15中會有二個「資料輸入、輸出介面」物件？這二個物件到底是不是同一個物件？還是作者筆誤？

98 圖7-15　購買當場次門票售票系統之合作圖

99 在這裡要說明的是，讀者在圖7-15中所看到的二個「資料輸入、輸出介面」物件，其實指的是同一個物件。看到這裡，聰明的讀者你可能又要問了，既然這二個「資料輸入、輸出介面」物件是同一個物件，為什麼要把它畫成二個？

100 在圖7-15中會把「資料輸入、輸出介面」物件畫成二個物件，主要原因是要讓這張合作圖看起來比較單純。如果要在圖中直接把本次購票價格的訊息由「計價」物件畫到「資料輸入、輸出介面」物件，因為在這二個物件間現階段並沒有連結存在，必須要重新畫一個跨越「場次」物件的連結，這會讓整個圖看起變比較複雜。

101 讀者爾後在繪圖的過程中，也需要常常考量到如何可使別人在看你的圖時，能夠一目了然，畢竟圖形是一種溝通的工具，不需要把它弄的很複雜，而影響到它最主要的功能─溝通。

102 五、系統出售季票之合作圖 依使用者（職棒聯盟）所提出來的系統需求顯示，球迷只能在各球場的售票口，經由售票員的服務才能購買當球季的季票，因此，在繪製系統出售季票的合作圖時，首先要了解到在出售門票的事件中到底會有哪些物件參與，經過分析後發現會有一個資料庫─場次座位資料庫─與三個物件─「資料輸入、輸出介面」物件、「場次」物件及「計價」物件，參與出售季票的作業。

103 其中「資料輸入、輸出介面」物件仍然是售票系統與外界的一個窗口，但是這一個窗口會比前一小節中的「資料輸入、輸出介面」物件單純許多，因為在前一小節中的「資料輸入、輸出介面」物件需接受來自自動售票機與位於售票口終端機的訊息，而在這一小節中，因為球季的季票只在售票口出售，所以，這個「資料輸入、輸出介面」物件簡單的說，指的就是位於售票口的終端機上的使用者介面。

104 在釐清了系統中的物件後，將各個物件置於圖中，並將各物件間的連結關係畫上，同時按照時間順序將物件間傳遞的訊息畫上，如圖7-16中所示。

105 圖7-16　購買季票之合作圖

106 首先購票者透過售票口的售票員，經由「資料輸入、輸出介面」物件輸入所欲購買的對戰組合及數量資料，「場次」物件在收到查詢訊息後，會根據所欲購買之對戰組合的場次，到場次座位資料庫中查詢目前這些場次的餘位數，並將所查詢到的餘位數傳回「資料輸入、輸出介面」物件。

107 在確認購票數量後，再經由「資料輸入、輪出介面」物件將購買數量傳給系統中的「場次」物件，「場次」物件在收到本次購票數量必須同步進行二件工作，在圖中以杜威表示法表示這二個巢狀訊息，首先是要把場次座位資料庫中的該場次座位數減少，這個作業表示在標示為6.1的訊息上，同時，要把訂票數量的資料送給「計價」物件，以便系統能計算本次購票的價格，這個作業表示在標示為6.2的訊息上。

108 「計價」物件根據由「場次」物件所傳來的訂票數量資料，計算本次購票的金額，並將計算出的結果透過「資料輸入、輸出介面」物件傳回位於售票口的終端機螢幕。在圖7-16中同樣的也看到了二個「資料輸入、輸出介面」物件，原因同前一小節中所述。

109 六、信用卡付費之合作圖 在前二節中分別討論了系統出售當場次門票與球季季票的合作圖，這一節接著要討論到付款作業，購買門票的付款方式有二種─付現金與以信用卡付費。球迷在現場購票時以現金支付票款，這是比較單純的作業，不在系統的討論範圍內，在這一小節中要討論的是球迷在購票時，若選擇以信用卡付款時，系統應如何處理。

110 經過分析發現球迷不管是利用自動售票機購票，抑或是在售票口經由售票員購票，若選擇以信用卡支付本次購票金額，其信用卡的資料一定要藉由一個設備才能進入系統，我們把這個設備定義成「信用卡資料讀取設備」物件。

111 其次，信用卡資料要透過網路傳到發卡銀行進行驗證，因此，也要有一個「輸入及輸出介面」物件來處理。當然，系統中一定要有一個處理信用卡資料的物件─「信用卡資料」物件，在確認了系統的物件後，即將這些物件分別放到圖上，如圖7-17中所示。

112 圖7-17　購票者以信用卡付費之合作圖

113 在圖7-17中，購票者的信用卡資料經由「信用卡讀取設備」物件進入售票系統，「信用卡資料」物件收到由「信用卡讀取設備」物件所傳來的信用卡資料後，即依照SSL的方式將其加密，並將加密過後的信用卡資料透過「輸入及輸出介面」物件送到「信用卡付費系統」物件，由「信用卡付費系統」物件將資料送交發卡銀行。

114 發卡銀行審核無誤後，「信用卡付費系統」物件會將發卡銀行授予本次交易的授權碼，經由「輸入及輸出介面」物件傳回售票系統中，售票系統中的「信用卡資料」物件在收到「輸入及輸出介面」物件所傳來的授權碼，即把本次交易的資料記錄在購票記錄資料庫中，而完成本次的交易。