顺序图与合作图.ppt

* * * * * * * 購票場次及數量資料透過「資料輸入、輸出介面」物件進入售票系統，「場次」物件先根據所欲購票的場次，到場次座位資料庫中查詢目前該場次的餘位數，並將所查詢到的餘位數傳回「資料輸入、輸出介面」物件。 在確認購票數量後，再經由「資料輸入、輪出介面」物件將購買數量傳給系統中的「場次」物件，「場次」物件在收到本次購票數量必須同步進行二件工作，在圖中以杜威表示法表示這二個巢狀訊息，首先是要把場次座位資料庫中的該場次座位數減少，這個作業表示在標示為6.1的訊息上，同時，要把訂票數量的資料送給「計價」物件，以便系統能計算本次購票的價格，這個作業表示在標示為6.2的訊息上。 「計價」物件根據由「場次」物件所傳來的訂票數量資料，計算本次購票的金額，並將計算出的結果透過「資料輸入、輸出介面」物件傳回自動售票機或位於售票口的終端機螢幕。聰明的讀者你可能會發現，為什麼圖7-15中會有二個「資料輸入、輸出介面」物件？這二個物件到底是不是同一個物件？還是作者筆誤？  圖7-15　購買當場次門票售票系統之合作圖 在這裡要說明的是，讀者在圖7-15中所看到的二個「資料輸入、輸出介面」物件，其實指的是同一個物件。看到這裡，聰明的讀者你可能又要問了，既然這二個「資料輸入、輸出介面」物件是同一個物件，為什麼要把它畫成二個？ 在圖7-15中會把「資料輸入、輸出介面」物件畫成二個物件，主要原因是要讓這張合作圖看起來比較單純。如果要在圖中直接把本次購票價格的訊息由「計價」物件畫到「資料輸入、輸出介面」物件，因為在這二個物件間現階段並沒有連結存在，必須要重新畫一個跨越「場次」物件的連結，這會讓整個圖看起變比較複雜。 讀者爾後在繪圖的過程中，也需要常常考量到如何可使別人在看你的圖時，能夠一目了然，畢竟圖形是一種溝通的工具，不需要把它弄的很複雜，而影響到它最主要的功能─溝通。 五、系統出售季票之合作圖 依使用者（職棒聯盟）所提出來的系統需求顯示，球迷只能在各球場的售票口，經由售票員的服務才能購買當球季的季票，因此，在繪製系統出售季票的合作圖時，首先要了解到在出售門票的事件中到底會有哪些物件參與，經過分析後發現會有一個資料庫─場次座位資料庫─與三個物件─「資料輸入、輸出介面」物件、「場次」物件及「計價」物件，參與出售季票的作業。 其中「資料輸入、輸出介面」物件仍然是售票系統與外界的一個窗口，但是這一個窗口會比前一小節中的「資料輸入、輸出介面」物件單純許多，因為在前一小節中的「資料輸入、輸出介面」物件需接受來自自動售票機與位於售票口終端機的訊息，而在這一小節中，因為球季的季票只在售票口出售，所以，這個「資料輸入、輸出介面」物件簡單的說，指的就是位於售票口的終端機上的使用者介面。 在釐清了系統中的物件後，將各個物件置於圖中，並將各物件間的連結關係畫上，同時按照時間順序將物件間傳遞的訊息畫上，如圖7-16中所示。  圖7-16　購買季票之合作圖 首先購票者透過售票口的售票員，經由「資料輸入、輸出介面」物件輸入所欲購買的對戰組合及數量資料，「場次」物件在收到查詢訊息後，會根據所欲購買之對戰組合的場次，到場次座位資料庫中查詢目前這些場次的餘位數，並將所查詢到的餘位數傳回「資料輸入、輸出介面」物件。 在確認購票數量後，再經由「資料輸入、輪出介面」物件將購買數量傳給系統中的「場次」物件，「場次」物件在收到本次購票數量必須同步進行二件工作，在圖中以杜威表示法表示這二個巢狀訊息，首先是要把場次座位資料庫中的該場次座位數減少，這個作業表示在標示為6.1的訊息上，同時，要把訂票數量的資料送給「計價」物件，以便系統能計算本次購票的價格，這個作業表示在標示為6.2的訊息上。 「計價」物件根據由「場次」物件所傳來的訂票數量資料，計算本次購票的金額，並將計算出的結果透過「資料輸入、輸出介面」物件傳回位於售票口的終端機螢幕。在圖7-16中同樣的也看到了二個「資料輸入、輸出介面」物件，原因同前一小節中所述。 六、信用卡付費之合作圖 在前二節中分別討論了系統出售當場次門票與球季季票的合作圖，這一節接著要討論到付款作業，購買門票的付款方式有二種─付現金與以信用卡付費。球迷在現場購票時以現金支付票款，這是比較單純的作業，不在系統的討論範圍內，在這一小節中要討論的是球迷在購票時，若選擇以信用卡付款時，系統應如何處理。 經過分析發現球迷不管是利用自動售票機購票，抑或是在售票口經由售票員購票，若選擇以信用卡支付本次購票金額，其信用卡的資料一定要藉由一個設備才能進入系統，我們把這個設備定義成「信用卡資料讀取設備」物件。 其次，信用卡資料要透過網路傳到發卡銀行進行驗證，因此，也要有一個「輸入及輸出介面」物件來處理。當然，系統中一定要有一個處理信用卡資料的物件─「信用卡資料」物