第十一章、互動圖.

Slides:



Advertisements
Similar presentations
教學與行政收費 E 化平台建置 總務處出納組 102/4/25. 前言 本校學雜、學分及招生報名費外之公 款繳納方式,由繳款人透過開立於中 信商銀 401 專戶辦理匯款 ( 金融機構或 ATM) 入帳,或親至出納組辦理。 為因應數位化及現代生活習慣,擬設 置繳費 E 化平台,同時收款通路將增 加全國四大超商、線上刷卡或網路.
Advertisements

1 97 年度新住民子女教育研討會 九十七年十月二十九日 柯伯儒 [1] 詹雅琄 [2] [1] [2] [1] [1] 國立台北教育大學課程與教學研究所博士生、 彰化縣二林鎮廣興國小主任 [2] [2] 國立台中教育大學課程與教學研究所研究生、 彰化縣二林鎮廣興國小教師 有效提升國小新住民子女 語文學習的策略.
語文教學分享心得 組員: B 蘇品綺 B 張慈真 B 陳怡君 B 蕭美玲 B 王雅萍 B 蔡佳珍.
環保 環保問題社會病態行為 從選購產品方面 家庭廢棄物的處理 住家的節約能源方面. 環保問題社會病態行為 社會功利主義過盛,疏忽善盡設備的責任; 缺乏惜福愛物的觀念,以自我為重心,任 意破壞使用資源; 「家」的觀念過度狹隘,只顧裝修生活的 表面,缺乏公同經營人類共有的家 — 地球 的概念; 無正確的理財觀念,而以金錢的謀取為目.
縮短公共工程工期之 招標決標策略及作法 行政院公共工程委員會 1. 簡報大綱 壹、前言 貳、招標決標策略及作法 参、適用案件類型 肆 、 結語 2.
博客來網路書店 case study 組員:吳權晉 張亦翔 詹尚瑾 吳昌育.
<<會計資訊系統課程講義>> 統一塑模語言(UML)語法精要 -- 物件導向概念、需求分析及系統分析
任务二 面向对象的建模 4. UML静态建模 类图 对象图 包图 组件图.
第 4 章 PHP 基本語法.
宿建德江 內容探究 問題討論 語文小詞典 絕句淺說 借代修辭 (補充說明借代法) 延伸閱讀 應用練習 (二)
母親的教誨 胡適 投影片設計:邱芳芸、謝瑞珍.
工 业 产 品 设 计 广义的工业设计:产品设计、环境设计、视觉传达设计。 狭义的工业设计:产品设计。
金融商品與服務之基本模式 時間 資金投入 風險 金融商品與服務 資金產出 2. 金融商品與服務之基本模式 時間 資金投入 風險 金融商品與服務 資金產出 2.
第五章银行负债业务 孙小平 经济教研室.
我征服了黃山 林達的黃山之旅 2006春.
建设工程保险制度案例分析 班级:建工134 学号: 姓名:韩秀昆.
Ch02物件導向程式設計 物件導向系統分析與設計.
岳麓版历史必修一 近代西方资本主义政体的建立 近代西方资本主义政体的建立 山东师大附中 侯新磊.
第4章 條件判斷與迴圈 Java 2 程式設計入門與應用.
如何生动形象地 写人记事.
金融产品认知 09会计3班 刘碧莲.
小组工作实训课(1) 第 教案 04.
國立空中大學台南中心  註冊工作簡報.
95學年度第一學期 國文科成果分享 報告者:李香瑩.
第12课时 对自己的行为负责 在承担责任中成长 考 点 聚 焦 考 题 探 究 考 点 拓 展 1.
第一章信託法 第一節 信託契約 第二節 信託財產 第三節 受益人 第四節 受託人 第五節 信託關係之消滅.
不为追"星"所累 (三) 第四课 青春故事 授课人:商城县汪桥一中王启学.
小儿营养不良 第四篇第二章第二节小儿营养不良.
2016年莱芜市乡村医生在岗培训 启动会.
大学生安全防范教育.
大学生安全防范教育 济宁职业技术学院 安全保卫处.
单元 SD 5 菜鸟学飞 附件二 想学飞的职场菜鸟.
第10章 考试系统的分析与设计 1.
普通高等教育“十一五”国家级规划教材 信息系统分析与设计 刘腾红 孙细明 主编 科 学 出 版 社.
歡迎蒞臨 一年二班家長日.
第八章 分析與設計階段 – 物件導向設計(OOD)
<<文獻學學習報告>>
节日安全指导手册.
网点常规审计管理办法.
2007 學校國民教育 交流研討會 學校經驗分享.
典藏豐富、深具特色的小型博物館 鹽分地帶文化館興建募款啟事 施工中 歡迎蒞臨參觀 建館緣由
主題課程的設計與實例 黃繼仁 課程發展與設計.
軟體工程 -物件導向程式設計與UML系統分析實作
第10章 使用個案塑模.
單元3:軟體設計 3-2 順序圖(Sequence Diagrams)
程式語言 I – VISUAL BASIC 選擇結構語法與應用 Chapter 7 認知
JUDE教學 Jude安裝教學篇 Jude初步介紹篇 Jude繪圖介紹篇 介紹jude的安裝和下戴 介紹jude的初基本功能
第9章 類別圖與物件圖 9-1 類別圖與物件圖的基礎 9-2 類別圖的符號 9-3 類別關係 9-4 物件圖 9-5 繪製類別圖與物件圖
7-1 互 動 7-2 順序圖 7-3 合作圖 7-4 順序圖的個案說明 7-5 合作圖的個案說明
UML类设计工具 任课老师:黄武 上午2时50分 10.
Advanced Basic Key Terms Dependency Actor Generation association
两种不同类别的软件: 功能预定义软件;用户驱动的软件。他们对软件工程方法有不同的需求
注音符號 首冊教學 說明.
管理信息系统 第九章 面向对象的系统开发方法.
Case 工具-UML with Rational Rose
证书发放工作要点及流程 学院办公室.
閩南語初階研習報告 《我的冊包》 改編自康軒版第一冊第二課 程詩嵐 林幸玫 李佩瑾 吳瑛瑛 李逸琦 朱嬿蓉.
2019/4/26 值得您列入生涯規劃的 一個重要選項 參加國家考試 考選部國家考試宣導小組.
幼稚園課程標準中的節奏樂器教學 4990U014李宜芸 4990U047陳靜芳 4990U049黃鈴珊 4990U050葉佩汾
第11章 物件互動行為塑模.
分組專題報告 陳錦蓮、陳麗妃製作.
沪粤版八年级物理 3.5 奇妙的透镜.
面向对象系统分析与设计 交互图.
客語歌謠-四季歌 台中市葫蘆墩國小教師 吳國銘 張郁棻.
注音符號教學 實務分享 公正國小 簡美月.
4. 曾文水庫越域引水環評報告彙整 資料來源: 1. 曾文水庫越域引水下游輸水工程環境影響差異分析暨環境現況差異分析及對策檢討報告(定稿本)
為民服務白皮書 台灣電力公司基隆區營業處.
106學年度四技二專技優甄審入學報名說明 1 1.
太陽能車、船競賽分享 主講:電子資訊學程 吳冠蓓 老師.
資格審查登錄系統-首次登入設定通行碼 若考生先前已於「繳費身分審查系統」設定過通行碼,則無須再行設定,直接登入系統即可.
Presentation transcript:

第十一章、互動圖

11.1 互動圖的目的 靜態觀點只是呈現物件如何被定義以及物件與物件的關聯性 (很類似 ERD),並不能透露出物件與物件之間是如何來互相溝通、傳遞訊息。 而動 態觀點,則是在捕捉這一方面的性質,它可以呈現出系統如何對來自使用者 的行動/要求做出反應,並且呈現出資料如何由儲存的地方移動到使用者的 畫面。

UML 2.0 定義了四種描述物件之間彼此互動情形的圖形,它們分別是: 循序圖 (Sequence Diagram):塑模出問題領域中物件之間互動的情形,重點放在描述一個使用案例執行的過程中,參與該案例之物件 與物件之間傳遞訊息的先後順序,強調訊息傳遞的時間性。 通訊圖 (C o m m u n i c a t i o n D i a g r a m):塑模出問題領域中物件之間互動的情形,重點放在描述一個使用案例執行的過程中,有哪些物件 必須參與該案例,並且透過合作,傳遞訊息,以完成一個使用案例; 強調合作物件之間的結構 (註:通訊圖在UML 1.0 時稱為合作圖) 。 互動概觀圖 (Interaction Overview Diagram):是一種活動圖的變形,用來描述高層次的控制流程以及它們之間的互動。 時序圖 (Ti m i n g D i a g r a m):當互動圖中的主要探討重點是有關於時間時。時序圖將焦點放在生命線或者生命線之間在時間軸上狀態的 改變。

在這四種互動圖中,以循序圖及通訊圖最為重要,因此,在互動圖這一 部分,本書將焦點放在這兩個圖形上。之前有提到循序圖是用來塑模動態模 型,該圖形強調的是時間,顯示參與一個使用案例的物件們,它們彼此之間 傳遞訊息時間上的執行順序;通訊圖也是用來塑模動態模型,但是它與循序 圖不同的地方在於它強調的是參與一個活動之物件之間的關聯以及結構。由 於市面上有許多的CASE 工具可以讓循序圖與通訊圖互相直接轉換,所以繪 製互動圖時只需要畫一種圖形即可。

11.2 互動圖符號 在循序圖與通訊圖中,我們使用跟物件圖相同的記號來表示參與的物件,你可以將物件圖當作是表達物件互動的靜態觀點,而將循序圖或是通訊 圖看作是物件互動的動態觀點。這裡所說的物件指的是從類別所建構出來的 具體實例 (Instance),從物件圖中,我們知道物件的表法如圖 11.1 所示。

圖11. 1表示一個沒有名字的實例,它的型別為Object。而圖 11 圖11.1表示一個沒有名字的實例,它的型別為Object。而圖 11.2則是表示 一個有名字的實例。在此,這個物件的名稱為a B o o k,它的型別或者我們說 它的類別型態為Book。

11.2.2 生命線 在互動圖中,我們稱參與互動的物件為生命線(Lifeline)。在循序圖中 表達生命線的方式不同於通訊圖。在循序圖中,生命線表法如圖11.x所示。 我們可以看到在循序圖中,生命線多了一條垂直虛線的尾巴。

11.2.3 連結線 我們知道循序圖主要是用來顯示參與一個使用案例的物件們,它們彼此 之間傳遞訊息的順序。當一個物件發送一個訊息給另一個物件時,傳送者必 須知道被傳送者的存在;在意義上,也就是說它們之間存在著某種關聯的關 係。所以,在通訊圖的表法中,使用一條直線來連結這兩端的物件用以表示(某種程度的) 關聯即連結線(Link)。

在訊息傳遞的表達上,採用一條帶有箭頭的直線來表示物件A傳送一個 訊息給物件B,物件A可以傳送訊息給其他的物件當然表示物件A知道它的存 在。值得一提的是在循序圖中我們是無法表達關聯關係,只能表達出訊息由 那個物件傳遞給那個物件;當我們把循序圖轉換成通訊圖時,關聯關係的直 線才會顯現出來。圖11.4是物件obj1與obj2的通訊圖,圖中顯示出物件obj1送 了一個名為message的訊息給物件obj2。

11.2.4 啟動生命線 前面有提到,市面上已經有許多的CASE 工具可以讓循序圖與通訊圖互 相直接轉換,因此,如果應用有這種轉換功能的C A S E工具,上面的通訊圖 可以轉換成如圖11.5的循序圖。

我們可以發現到在物件的生命線中出現了長條方形的圖形,這個圖形叫做啟動生命線(Activation Lifeline),或者就稱為啟動(Activation);在 UML 2.0 中,也稱其為控制焦點 (Focus of Control),這代表著系統在執 行的過程中,某物件在某個時間點上因為接收到某種訊息而被啟動並且擁有 了控制權。另外,值得注意的是,循序圖中無法顯示出物件與物件之間的關連線。

11.2.5 訊息 在循序圖與通訊圖中,訊息是一條帶有實心三角形箭頭的直線,此類訊 息(Message)稱為同步訊息。在此訊息上我們可以寫上一些簡述用以描述 該訊息所要表達的語意,對於訊息的描述可以只是簡短的文字敘述。例如在圖 11.6的循序圖中,物件obj1傳遞了一個名稱為message的訊息給obj2。

有許多的書比較喜歡用通訊圖來表示動態模型,一個簡單的原因是因為 通訊圖在繪製上所佔用的空間一般來說都比循序圖來得少。關於這一點,你 可以用圖11.4和11.5來做比較,當參與的物件變得很多的時候,循序圖就會佔 據較長的篇幅,因為在循序圖中,生命線是以水平的方式依序排列出來。

一個物件可以傳送訊息給其他的物件,當然也可以傳送訊息給它自己, 如圖11.7所示,這個時候連結線是從自己連結到物件自己本身。

一個物件可能傳送不只一個訊息給另一個物件,那麼根據它傳遞的時間順序,我們可以為每個訊息加上所謂的序號來顯示呼叫的次序,圖 11 一個物件可能傳送不只一個訊息給另一個物件,那麼根據它傳遞的時間順序,我們可以為每個訊息加上所謂的序號來顯示呼叫的次序,圖 11.8顯示 了obj1傳送訊息message1給obj2,過了一段時間之後,obj1又傳送了另一個訊 息message2給obj2。它所表達的含意是obj1請求obj2 執行 message1,執行完 畢之後,過了一段時間,obj1又傳遞了另一個訊息 message2 請求 obj2 執行。

另外,從圖11.8中我們看到有一條虛線從obj2 指向 obj1。在循序圖中, 此虛線代表回傳訊息 (return message),對於一個啟動的回傳訊息並不一 定要繪製出來,所以,對於 message2() 我們刻意不畫出回傳訊息。

上面所說的訊息是指同步的訊息 (S y n c h r o n o u s M e s s a g e)。然而對 於 某 些 系 統 來 說 , 除 了 同 步 的 訊 息 之 外 , 系 統 有 可 能 產 生 非 同 步 的(Asynchronous) 訊息以處理其他的事項。非同步訊息的表法為一條帶有 箭頭的直線,如圖11.9所示。所謂的同步訊息是指當該訊息一旦被啟動,則 只有等到啟動生命線結束之後,訊息才會回傳給呼叫者;而非同步訊息是一 旦啟動之後,會立刻返回呼叫者,呼叫者會繼續執行接下來該執行的動作而 不會等待非同步訊息的回傳。

在此,我們舉一個非同步訊號的應用例子。在一般典型的We b 2.0 應用 網站上我們常見到採用Ajax 技術來執行非同步的請求。 基本的Ajax請求之循序圖可以塑模如圖11.10。從此圖中,我們可以看到使用者在執行登入 的案例,登入的訊息在J a v a s c r i p t中被啟動,而這個啟動的過程中,它會執 行一個非同步的動作 send()將使用者的資訊傳送到伺服器端去驗證。然而, 在等待伺服器驗證的同時,使用者還是可以繼續其動作而不會有影響 (例 如:繼續瀏覽畫面等等)。一旦伺服器處理完畢,回傳到客戶端,客戶端的 Javascript 回呼函數會接著執行接下來所必須的工作 (例如:改變使用者的 畫面變成會員的畫面)。

11.2.6 產生 / 消滅訊息 一個物件在可以開始它的生命之前必須被產生,一旦完成它所付與的任 務之後可能需要被從系統中消滅掉,於循序圖中,我們也可以表達這兩種情 況。產生與消滅(Create and Destroy Message)這兩個訊息的圖形與一般 的同步訊息一樣,均為一條帶有實心三角形箭頭的直線。對於產生訊息,我 們只是在訊息上面多加了一個造型 <<c re a t e>>用以表示這是一個產生的訊 息;而對於消滅訊息則是在訊息的上面加上造型 <<destroy>> 並且在生命線 的尾端劃上一個大叉叉,如圖 11.11所示。此圖說明object2 首先被 object 1建 立,接著object1 傳送了一個 process() 的訊息給object2,最後,object1 消滅了 object2。

11.2.7 訊息參數 當一個物件傳遞訊息給另一個物件的同時,訊息也可以一起傳送參數, 這就好比像在程式中當我們呼叫一個函數時, 我們也會將這個函數所需的引 數一起傳遞。因此,如果你把訊息想像成結構化程式中所謂的副程式呼叫, 那就對了!唯一不同的是,在物件導向的語言中不存在所謂的副程式這種說 法。一般來說,參數的表法是採用下列的格式: 參數名稱:型態

圖 11.12顯示一個叫做john的學生送了「註冊課程」這個訊息給系統,連 同這個訊息一起傳送的是他所想要註冊的課程;這個課程物件叫做cour, 並 且在傳送的訊息中,我們也顯示出它的類別型態- 課程 (Course)。

11.2.8 訊息回傳值 假如一個訊息有回傳值(Return Value)的話,你也可以將它在循序圖中表示出來。以圖 11.12 為例,當註冊課程成功時,我們希望這個訊息能夠 傳回一個整數,並且將這個整數存放在一個名為result的變數中,如此一來, 我們可以用如圖 11.13 所示的表法:

11.3 進階符號

11.3.1 框架 UML 2.0中定義了框架(Frame)的圖形,如圖 11.14,框架為一個長方 矩形,在其左上角有一個五邊形的標題區域,在標題區域內,我們可以給定 此框架所包含之元素的種類以及框架名稱,框架名稱基本上描述該框架所要 表達的語意。

應用於互動圖中的框架,UML 2.0定義其種類表法使用sd。例 如:圖11.15是一個使用框架的「下訂單」互動圖。

11.3.2 組合片段 當我們描述一序列的互動過程時,有某些特定的步驟可能需要滿足某些條件才會繼續進行下去,或者是我們可能必須要使用迴圈來處理某個集 合類中的元素,這些片段稱為互動片段 (Interaction Fragment)。UML2.0 中定義了一種新的圖形稱為組合片段(C o m b i n e d F r a g m e n t)用來包含這些互動片段。組合片段的主要用途在於分解循序圖,讓循序圖中可以表達更豐富的語意。根據U M L 2.0的定義,組合片段定義了互動片段的表 達式(E x p r e s s i o n),因此,組合片段包含兩部分:一個稱為互動運算子(Interaction Operator),互動運算子由簡單的英文字母所組成;另一個稱 為互動運算元(Interaction Operand),互動運算元包含一個或多個互動片 段,組合片段結構如圖11.16所示。

下面我們列出幾個比較常用的互動運算子並且以例子來說明如何在塑模 互動的過程中使用它們。

1. opt:用於只有當條件成立時,才會執行單一運算元。此運算子很類似 於程式語言中的:if (條件) then 動作。 範例:「⋯當我們去提款機提款時,我們首先會插入卡片,系統這時候會 驗證卡片的有效性,當卡片是有效時(Valid),系統會要求我們輸 入密碼⋯」。對於這段描述,我們可以使用o p t組合片段表達於循 序圖中,如圖11.17 所示。

2. alt:用於表達多種選擇,當條件成立時,才會執行相關的運算元。此運算子很類似於程式語言中的: if (條件1) then 動作 1 else if (條件2) then 動作2 else 動作3 範例:「⋯當我們去提款機提款時,我們首先會插入卡片,系統這時候會 驗證卡片的有效性,當卡片是有效時(Valid),系統會要求我們輸 入密碼;而當卡片是無效時,系統會顯示無效訊息⋯」。對於這段 描述,我們可以使用alt組合片段完整地表達於循序圖中,如圖11.18 所示。

3. loop:用於表達迴圈,被包含之互動運算元會被執行許多次,loop的 條件式表法為 minint, maxint [條件],或者是 [for each 物件]。 範例: 「⋯計算購物車中訂購項目的總金額⋯」這句描述可以利用l o o p 組合片段表達如圖 11.19所示。當購物車接收到計算總金額的訊息 時,購物車首先將其總價歸零,然後對於購物車中所包含之各項訂 購項目,依序執行「取出單價,將單價加入總價」的動作。

4. break:用於跳出迴圈。一般來說,會在break 後面加上條件,用於表達當條件為真時,被包含之運算元會被執行。另外,break組合片段的 繪製必須涵蓋到所有被包含之生命線。 範例:「 ⋯ 顧 客 搜 尋 產 品 ⋯ 」 。 假 設 說 所 有 的 產 品 目 前 放 在 集 合 物 件 products 中,而搜尋產品時,必須逐一比對各產品之產品編號是否 與想要搜尋之產品相同;如果是的話,則回傳此產品,不是的話, 回傳空物件(Null)。利用loop 以及break,我們可以將此描述以 循序圖表達如圖11.20。

5. ref:參照其他的互動。對於複雜的流程步驟,我們可以將其互動的流程繪製於某個組合片段,然後在需要參照到這些組合片段的步驟中使 用re f。 例如在圖11.21中,當AT M系統顯示選擇畫面給顧客時,顧客 可能有的動作包括選擇提款或是選擇查詢餘額的動作,提款與查詢餘 額這兩個案例的執行細節我們可以從目前的流程中獨立出來,並且於 互動圖中使用ref組合片段來說明請參考相關的互動圖。在UML 2.0 中 稱ref組合片段為「互動使用」(Interaction use)。互動使用不僅可 以出現在循序圖中,它們也常常出現在互動概觀圖上。

除了上述幾個常見的的組合片段之外,組合片段還包括有: 6. critical :表達一個critical 區域,亦即是運算元在此組合片段中執行時 不可被中斷。 7. neg :表達此組合片段為無效,不可能參與互動。 8. assert :表達斷言以確保某個動作的執行。 9. ignore :表達那個訊息在互動中應該被忽略。 10. consider :表達那個訊息在互動中應該被考慮。

11.3.3 互動概觀圖 本章一開始有介紹到互動概觀圖(Interaction Overview Diagram)是活動圖的一種變形,其作用在於描述高層次的控制流程以及它們之間的互 動。在互動概觀圖中,除了動作(Action) 圖形之外,均使用與活動圖中相 同的圖形,例如活動開始、活動結束、分叉、決策等等;而被取代的動作圖 形改用「互動使用」(Interaction Use)或者是其他的互動圖元件。

圖11.22是一個使用互動概觀圖來描述借書的執行流程。圖中使用到互動 使用元素來告訴讀者這個部分請參考其他相關的互動圖以了解其細部內容以 及互動流程。

另外,在循序圖繪製過程中,如果我們發現到某些互動流程會重複出 現,那麼我們可以使用「互動使用」來表達此片段活動。舉例來說,圖11 另外,在循序圖繪製過程中,如果我們發現到某些互動流程會重複出 現,那麼我們可以使用「互動使用」來表達此片段活動。舉例來說,圖11.23 表示一個登入的互動圖,而在圖11.24中之瀏覽書籍互動中,我們繪製登入的 互動使用,其意思代表著對於登入這個互動的過程請參閱登入的互動圖。

11.4 系統循序圖

11.4.1 系統循序圖 我們知道使用案例所描述的是系統所提供的功能,而使用者與系統之間 的互動細節,可以用使用案例規格書敘述下來,除此之外,使用案例規格書中記載著執行一個使用案例的正常路徑、例外路徑等等資訊。一個系統外 部的使用者與系統之間的互動以及訊息傳遞,基本上都可以利用循序圖來表 達;有時候,我們就稱這種循序圖為「系統循序圖」。 讓我們用「 顧客訂購C D」使用案例來說明系統循序圖的概念。顧客訂 購CD使用案例的基本路徑如下:

1. 顧客選擇其中的一個CD以查看更多的資訊 2. 系統顯示顧客該CD的基本資訊 3. 顧客把CD放入到購物車. 4. 系統顯示購物車內容 5. 顧客結帳 (Check-out) 6. 系統顯示登入畫面 7. 顧客提供登入資料E-mail跟密碼 8. 系統驗證登入資料 9. 系統驗證顧客的信用卡資料 10. 系統儲存訂單交易資訊 11. 系統寄發訂單確認函(E-mail)給顧客 12. 系統顯示訂單交易明細資訊

在此,我們再重複一次何謂路徑:路徑是描述在一個使用案例中,使用者與系統之間的互動以完成這個使用案例的流程。所以,在一開始繪製循序 圖時,我們可以繪製兩個簡單的物件:一個物件代表使用者,另一個物件代 表系統(圖11.25)。因為在我們的使用案例中,使用者其實是泛指所謂的顧 客,所以用顧客 (Customer) 來代表我們的使用者;不過,這兩個物件都 是無名的 (Anonymous) 物件。

接著,我們可以就使用案例規格書中的每一條敘述利用訊息傳遞的方式來表達。基本上,訊息的寫法以動詞為開端,系統回應給使用者的部分則可 以採用「顯示⋯」以代表系統的回應。利用這個做法,我們將上述的使用案 例基本路徑繪製成如圖 11.26 (系統) 循序圖。

在分析階段時,循序圖應該捕捉到使用案例的正常路徑;而對於使用案 例中的場景 (Scenario) ,我們可以進一步地利用循序圖來做分析。對於不同的場景,它也應該有一個對應的循序圖,或者是利用組合片段將其畫於同一張循序圖上。

這裡,我們來看一下循序圖與其他圖的差異: 循序圖捕捉特定的場景, 而使用案例描述一般來說包含多個場景。 對於一個使用案例,我們可以利用活動圖來顯示多個路徑或是平行的工作,在以往UML 1.x 中,循序圖只能表達出一個使用案例的某個特 定路徑,所以對於不同的場景,我們必須要繪製不同的循序圖。而從U M L 2.0開始,使用組合片段或是互動概觀圖,我們可以只使用一張 循序圖來表達整個使用案例的執行流程與細節。

11.4.2 精練系統循序圖 讓我們以自動提款機 (ATM) 的轉帳使用案例做為範例來說明,如圖11.27所示。

如圖 11.27的初步的循序圖勾勒出使用者與系統的基本互動,但是也帶給 我們有更多的疑問。例如說,使用者是如何要求轉帳的?系統是如何知道以 及提供客戶的帳戶?⋯等等,這些疑問都是必須仔細地加以分析以及檢驗。 由於循序圖的繪製不會一次就完成,以上所提的問題,也會隨著對領域問題 有更深的了解後,在接續的過程中慢慢得出答案。圖 11.28是在與領域專家仔 細討論過後,再加以精練所得之轉帳系統循序圖。