工具系列：UML狀態圖

本篇介紹UML狀態圖。狀態圖是用來表達系統執行的狀態，特別要顯示系統在不同狀態之間有不同的行為。系統的每一項活動或操作步驟會使一個狀態轉移為另一個狀態。通常，狀態圖關心的範圍相當小，只和一個類別或元件有關。

以下先介紹狀態圖的圖示，然後給一個示範。

一、UML狀態圖的圖示

• 狀態：(State) 用圓角方形、其中寫狀態名稱，表示一個狀態。圓角方形中間可打一橫線，線下方標示該狀態的效果。


• 效果：(Effect) 以格式為 "動作類型 / 動作" 的文字，描述一個狀態的進、出、及運作的效果。動作類型有 Entry, Exit, 和 Do 等等。動作可以是類別的操作方法、或是簡單的動詞。對一項狀態來說，如果同一組動作類型的行為都有同樣的效果，則應該將此狀態效果寫出來。
• 傳遞：(Transition) 從一項狀態拉出帶箭頭的線、到另一項狀態、並在線上標識名稱，表示從一項狀態傳遞到另一項狀態。


• 傳遞標籤：(Transition Label) 以格式為 "事件 [限制條件] / 動作效果" 的文字，描述一項狀態滿足條件時會觸發一項事件、轉為另一項狀態，並且造成一項效果。事件(event)若使用英文應記為過去式動詞。限制條件是一則判斷式，為了表達明確，不要使用重疊的限制條件，例如 x <= 0 是重疊的，應該分為 x < x =" 0" style="font-weight: bold;">動作效果要標記類別的操作方法；動作效果和狀態效果有相同意義。
• 起動狀態：(Initial State) 用實心圓點表示起動狀態。起動狀態拉出的傳遞線不能有限制條件。
• 結束狀態：(Final State) 用外圍圓邊的實心圓點表示結束狀態。
  

二、UML狀態圖的示範

以下示範一台讀卡機的狀態圖。

工具系列：UML活動圖

本篇介紹UML活動圖(Activity Diagram)。UML活動圖和一般的程式流程圖非常像，並多了能夠描述平形處理的能力。活動圖可表達流程，可用在描述複雜的操作過程、複雜的業務規則、一項或多項使用案例、或一項或多項商業流程。

以下，先介紹圖示及使用方式，接著展示一項示範。

一、UML活動圖的圖示及使用方式

• 活動：(Activity) 用圓角方形、其中寫上活動名稱，表示一項活動。一項活動可以是呼叫一項操作方法、執行一項步驟、或是商務流程中的一項。
  


• 使用案例：(Use Case) 用橢圓型、其中寫上案例名稱，表示一項使用案例。在UML活動圖中，可以將一項使用案例當做一項活動來配置。


• 起點：(Start Point) 用實心圓點表示起點。一張UML活動圖必須有一個起點。
  


• 終點：(Ending Point) 用實心圓點外加一環邊界，表示終點。一張UML活動圖可能沒有終點：例如，連續的流程。
  


• 流程：(Flow/Edge) 從一項活動拉出帶箭頭的線、到另一項活動，表示一條流程從一項活動到另一項活動。
• 決策點：(Decision Point) 用空心菱形表示一個決策點。決策點有一條流程流入、並有多條流程流出，其中，在多條流出的流程中可挑選執行其中一條流程。
• 決策條件：(Guard/Condition) 用格式為 [測試條件] 的文字、附在決策點流出的一條流程線上，表示一項決策條件。一個決策點的每一條流程都必需有決策條件。


• 合併點：(Merge Point) 用空心菱形表示一個合併點。合併點有多條流程流入、並有一條流程流出。合併點隱含在多條流入的流程中、根據流出流程的決策條件、有一條或多條流程要抵達，才能進行流程合併之後的工作。


• 分岐：(Fork) 用一條粗線橫擋、有一條流程流進、並多條流程流出，表示一份平行工作的開始。


• 結合：(Join) 用一條粗線橫擋、有多條流程流進、並一條流程流出，表示一份平行工作的結束。流程的合併隱含了所有流進的流程都要抵達、才能進行流程結合之後的工作。


• 泳道：(Swimlane) 用大長條方塊、一端加上標籤欄位，表示一條泳道。泳道是UML活動圖中用來將一部份的活動和其他物件劃分為一群的空間。泳道的標籤名稱通常是一項參與者的名稱，表示該泳道包含的活動和一位參與者有關。有些泳道用來代表一段執行緒，則不標識為參與者名稱。
• 分群：(Partitioning) 用併排的多條泳道、將UML活動圖的全部或一部份劃分，表示此圖有一些分群。

二、UML活動圖的示範

以下示範「使用者靠卡登入 RFID 系統」的活動圖。

工具系列：UML溝通圖

UML溝通圖(Communication Diagram)，在前一版UML中稱為合作圖(Collaboration Diagram)，顯示物件之間的通訊順序。溝通圖乍看與順序圖的功能有些重疊，不過，溝通圖突顯訊息傳遞的順序和分群、而後者則突顯物件運作的順序。

以下，先介紹溝通圖的圖示，再舉出一個示範例子。

一、UML溝通圖的圖示

• 物件：(Object) 用長方形代表一項通訊個體、其中寫物件名稱、所屬類別名稱、並加底線，表示一項物件。


• 關聯：(Relationship) 從一項物件拉出一條線到另一項物件，表示一項物件和另一項物件有關聯。關聯可能是一般、組合、或彙總等類型，在本圖型不畫出關聯的細節。


• 訊息：(Message) 在關聯線上畫出帶箭頭直線，表示帶有方向的通訊訊息。箭頭線上要加上一個或多個訊息標籤，表示在同一條關聯線上、先後有一些訊息傳遞。訊息標籤格式是 階層式標籤代號 : 操作方法 (參數列) : 傳回值 、傳回值可省略。同一關聯線的同方向訊息，可共用一條箭頭線。

二、UML溝通圖的示範

以下示範RFID門禁管理系統的UML溝通圖。訊息要按照先後順序編號，並且可以將同一項案例的訊息分群並列為子訊息。

工具系列：UML順序圖

本文介紹UML順序圖(Sequence Diagram)。順序圖是討論系統中物件彼此溝通時、全部操作的順序。因此，圖中應該列出物件、物件的並存、訊息、以及通訊方向。以下說明圖示的畫法及擺設方式，接著再給一個示範。

一、UML順序圖的圖示

• 參與項目：(Participant) 將參與的物件水平地擺開，並取適當距離、提供後續繪圖空間。參與的物件，包含在使用案例圖定義的參與者和外部實體、以及在物件圖定義的物件。挑選適當數目的參與項目，使順序圖的主題比較突顯。
  
• 生命線：(Lifeline) 從每個物件下方、向下拉出虛線，表示物件運作的時間範圍。通常，同一張圖的每個物件生命線都一樣長；而若一項物件比其他物件更早消滅(從記憶體移除)，要在生命線末端添加交叉線符號(X)，並且該物件的生命線比其他物件的生命線短。
  


• 活動：(Activation) 在生命線上拉出一塊空白縱長方形，表示該參與項目在運作範圍內、有一段活動的時期。活動來自程序呼叫，因此活動方塊也可以稱為程序呼叫方塊(Method-call Box)。物件接受一項程序呼叫、啟動活動時期、最後再傳回結果。
  
• 訊息：(Message) 用帶有箭頭的水平線、並在上方加上訊息名稱，表示一項訊息或操作過程的呼叫。線有三種類型：(1) 實線和實心箭頭、代表同步訊息；(2) 實線和線條箭頭、代表非同步訊息；(3) 點線、代表傳回值(return value)。實線是用來呼叫程序，訊息名稱是「操作方法(參數列)」的形式；虛線是用來表示回應訊息，訊息名稱是傳回值的名稱。
  


• 通訊起點：可能從一項參與項目先發出訊息，從該項目的生命線直接拉出第一條訊息線。或者，可能不是從任何參與項目先發出訊息，則從左端畫一粒黑點、從黑點拉出第一條訊息線。

二、順序圖的示範

以下示範一般用戶登入 RFID 系統的順序圖，即門禁管理的案例。用戶靠卡創造啟動訊息；讀卡機查詢特定方向、讀取卡片代碼和密碼；接著，讀卡機將密碼加密，傳送到系統；系統藉資料庫代理人取得用戶密碼；系統將讀卡機送來的密碼解密、並與資料庫代理人送來的密碼比對，傳回結果；系統向讀卡機傳送登入狀態；最後，讀卡機對用戶呈現接收情況。

示範的順序圖如下：

工具系列：UML物件圖

UML物件圖是由類別圖產生實例，表達系統結構在執行的情況。物件圖可以只畫出我們要討論系統的部份情況。

• 物件：(Object) 用二個長方形、由上而下依序標示物件名稱和屬性實例，表示一項物件。物件是某個類別的一項實例。第一個長方形要寫物件名稱和類別名稱，中間用冒號(:)區隔、並在下方劃底線。第二個長方形列出較重要的屬性、以及對應的值，屬性和值用等號(=)區隔；多值屬性的值要用大括號 { } 包圍、並使用逗點(,)區隔每一項值：例如，{Grady Booch, James Rumbaugh, Ivar Jacobson} 。在必要時，第二個長方形可以省略：例如，物件名稱也可以省略。

• 連線：(Link) 從一項物件拉出一條線到另一項物件，表示一項物件連接到另一項物件。連線的二端可以視需要添加文字標籤。連線(link)是類別關聯(association)的實例，所以如果標示連線名稱、要加底線。


• 參與數目：(Multiplicity) 從一項物件拉出多條線到其他一些物件，表示一項物件和其他物件的關係。拉出線條的數目應該符合類別圖描述的類別關聯參與數目：例如，讀卡機可以讀一組卡片。


• 彙總/組合：(Aggregation/Composition) 類別圖可用的彙總和組合等關聯，也可以用在物件圖。

工具系列：UML類別圖

本文介紹UML的類別圖。類別圖是從類別觀點看系統的結構；物件圖則顯示系統結構在某個時間的實例。二種圖式有一部份是大同小異、並互通有無。以下段落依序介紹類別圖的圖示與示範。另一篇將介紹物件圖。類別圖描述系統的基本結構，並且模型建構符合當前的物件導向程式語言模型，例如Java；於是，類別圖非常適合當做在系統分析階段對程式人員解說的文件。

• 類別：(Class) 主要用四個長方形從上向下層疊、其中以文字標明各段內容，依序表示類別名稱、屬性、操作方法、以及責任。屬性和操作方法可以用 + 或 - 等前綴符號表示存取能力是公開或私有，另外，或者可用 # 標示保護屬性、以及用 ~ 標示包裝(即若干個類別的集合)。屬性的主體包含屬性名稱、和屬性的資料型態或類別。操作方法的主體包含方法名稱、括弧標示的參數項目、和方法的資料型態或類別。操作方法的參數要寫上參數名稱、和參數的資料型態或類別。如果操作方法有許多參數，要用逗點(,)分隔。第四個長方形要寫物件的責任，並且第四個長方形可以按需要而省略。
  
  有時為了省略細節、而使表達較簡單又清楚，可以將類別屬性和操作方法的描述文字省略。或者，也可以把第二個長方形和第三個長方形省略，只用一個帶有類別名稱的長方形表示類別。


• 關聯：(Association) 在一個類別和另一個類別之間拉出連接線、並在上方標示關聯詞(動詞)、二端視需求可標示參與數目和介面名稱，表示二個類別之間的關聯。例如，一或多個「數字」「標記」一種「物品」。參與數目(multiplicity or cardinality)可能標示為數字、表示多項的代用符號(*) 、或是像 "0..1" 的數字區段。可以在關聯詞旁邊以實心三角形標示方向。



• 彙總：(Aggregation) 在連接線的一端加上空心菱形，表示一項類別(菱形端)對另一項類別有「整體與部份」的關聯。彙總的意思是 has-a ，通常是強調一項類別(菱形端)的包含了另一項類別的集合：例如，讀卡機可以讀一組卡片。


• 組合：(Composition) 在連接線的一端加上實心菱形，表示一項類別(菱形端)除了對另一項類別有「整體與部份」的關聯之外、而且是由另一項類別組成。組合的關聯力比彙總強，組合隱含了：如果一項類別(菱形端)的實例毀壞，它包含的另一項類別組成物也都毀壞。例如，讀卡機內含晶片。此外，組合的菱形端參與數目必須是 0..1 或 1 。


• 一般化/特殊化：(Generalization/specialization) 在連接線的一端加上空心三角形，表示一項類別(三角形端)是另一項類別的一般樣式；相對地，另一項類別是該類別的特殊樣式。一般化的意思是 is-a ，也是繼承的關係：例如，MT180/FP 是一種讀卡機。MT180/FP和MP-602MUSx是Reader的子型(subtype)，而Reader是母型(supertype) 。
  
  可注意，一般化也可以用在使用案例圖，用來處理案例或參與者的從屬層次。


• 實現：(Realization) 用帶箭頭的虛線從一項類別拉到另一項類別、並在上方標示用雙角括號 « » 包含的關聯詞(動詞)，表示一項類別實現了另一項類別的行為：例如，讀卡機實作天線的用途。


• 依賴：(Dependency) 從一項類別拉出一條帶箭頭的虛線到另一項類別、不帶標示文字，表示一項類別依賴另一項類別提供的功能。
• 端口：(Port) 從一項類別拉出一條線、另一端以小空心圓結尾並附帶端口名稱，表示一個輸入端。而另一端以小半圓弧結尾，則表示一個輸出端。端口的圖示也出現在UML元件圖，另一篇將再介紹。
• 介面：(Interface) 從一項類別拉出一條虛線到另一項類別、並在另一端加上空心三角形，表示一項類別實作另一項類別(三角形端)的介面定義。介面類別要在類別名稱上方標示«Interface»文字 。介面的定義必須反映實作語言的限制。

工具系列：UML概觀、及使用案例圖

UML(United Modeling Language)是一套圖型語言，可以描述模型和概念。UML是大約1999年有Grady Booch、James Rumbaugh和Ivar Jacobson三人，都在做模型建構的研究，而共同創造了UML。他們三人稱為UML的「三劍客」(3 Amigos)。電腦資訊系統分析與設計的學問，除了過去有階層式(瀑布式)的開發生命週期之外，還藉由採用UML帶來物件導向分析設計方式。

版本區別，在幾年前有UML第一版、區分為十一種圖式；最近UML已經是第二版，有十三種圖式。

UML的圖式，按思考的方面及使用場合區分，有功能觀點、物件觀點、動態觀點等方面。

• 功能觀點：從用戶的觀點看系統模型，主要圖式為使用案例圖(Use-case Diagram)。
  
• 物件觀點：關心物件的屬性、操作和關係，主要圖式有類別圖(Class Diagram)。
  
• 動態觀點：關心系統的內部行為，主要圖式有順序圖(Sequence Diagram)、活動圖(Activity Diagram)、和狀態圖(State Diagram)等。
  

按圖式的內容物劃分，十三種圖式分類為結構類、行為類和溝通類。

• 結構類：有類別圖、物件圖(Object Diagram)、複合結構圖(Composite Structure Diagram)、元件圖(Component Diagram)、包裝圖(Package Diagram)和部署圖(Deployment Diagram)。
  
• 行為類：有活動圖、狀態圖和使用案例圖。
  
• 溝通類：有溝通圖(Communication Diagram)、順序圖、互動圖(Interaction Overview Diagram)和時間圖(Timing Diagram)。最後二種是由UML第二版增添。
  

使用案例圖。使用案例圖是描述使用案例的圖式。一般來說，適合讓專案管理師(PM, Project Manager)或資訊架構師(Information Architect)使用，用來跟客戶溝通。一份使用案例圖，要表達出一份案例或使用情境，除了要使用明白的圖例之外，還要根據合適的情節腳本來繪製。以下先介紹可使用的圖例，接著示範一個實際的使用案例圖。最後，談到腳本的撰寫。

一、使用案例圖的圖例

• 標題：在圖上方以文字標明本使用案例圖的名稱。
• 參與者：(Actor) 用最簡單的筆劃劃出人型圖示，表示一位或一些可執行操作的角色。可在圖示下方標示名稱與類型；類型(stereotype)放在名稱上方，並以雙角括號« »包圍。



• 案例：(Case) 用橢圓形、中間寫上案例名稱(以動詞為主)，表示一份系統提供的服務或功能。



• 關聯：(Association) 用線段連接參與者和案例、或連接案例和另一個案例，並且可用箭頭表達方向，表示一樣東西和另一樣東西的關聯。案例和案例之間的關聯，有包含(inclusion)和擴充(extension)二種。
  
• 包含的關聯：(Including association) 從一個橢圓拉出一條虛線、到另一個橢圓，並在虛線上標示«include»文字，表示一個案例包含另一個子案例。例如「登入」包含「讀取帳戶」。



• 擴充的關聯：(Extending association) 從一個橢圓拉出一條虛線、到另一個橢圓，並在虛線上標示«extend»文字，表示一個案例擴充另一個案例。例如，「檢查其他位置登入」擴充「登入」。



• 系統範圍：(Boundary) 用大方形包圍一些圖例、與其他圖例隔離，並在大方形邊緣可用文字標明系統名稱，表示在範圍內的項目屬於同一個系統。而在範圍外的項目稱為外部實體。
  
• 外部實體：(External entity) 用方形、中間寫了實體名稱，表示一項與系統溝通的外部實體。參與者也是一種外部實體，通常表達為人型圖示。而其他系統或其他組織，則用方形圖示。

二、示範

以下為一項使用案例圖的示範，可注意圖中案例從上往下的順序隱含了操作流程。校園識別卡印卡系統有「登入」和「印卡」二件案例。「登入」要從校務系統「讀取雇員資料」，並且「檢查重覆登入」保證雇員只從一處服務據點工作。「印卡」要從校務系統「讀取服務對象資料」才能印卡。

三、腳本的撰寫

繪製使用案例圖是將一些使用案例畫出來；而使用案例通常是複雜的。為了讓使用案例圖不畫得凌亂，並且讓使用案例在過於簡單與過於複雜之間找到適合的份量，有些書籍特別談到使用案例的撰寫：例如，「使用案例寫作實務」(博客來網路書店的書樣：http://www.books.com.tw/exep/prod/booksfile.php?item=0010225897)。

使用案例，是一串事件清單，可表達一份使用情境。像撰寫一般故事一樣，先寫一條順利完成動作的主線清單。接著，思考每一項事件的旁支案例，它相對於主線清單、包含了一些例外以及對應的處置事件。將案例分支交待完了之後，系統的行為就顯得清楚。

使用案例圖和使用案例，是跟著使用者的觀點看系統模型；於是，特別適合在系統發展初期做與客戶溝通的文件。使用案例圖提供一目瞭然的效用，使用案例腳本則描述系統行為，二者相輔相成、幫助釐清系統全貌。

工具系列: 用心智圖整理思想

思想是不容易掌握的事物，而且對記憶力差的人特別是這樣。思想的組織，可能有許多詞彙和彼此的關聯構成。要讓資訊記得住，人腦要掌握思想網狀組織的全貌。

心智圖(Mind Map)是跟著網狀或樹狀心理模型而出現的工具，將思想對應的詞彙和關聯畫在紙上。心智圖可以隨著工作的過程一起發展、擴大，也可以在繪圖告一段落時讓思想一目瞭然。網路自由軟體社群 SourceForge 有一個軟體專案提供了漂亮的心智圖軟體 FreeMind (http://freemind.sourceforge.net/，網址會自動連到 http://freemind.sourceforge.net/wiki/index.php/Main_Page )。

心智圖的結構，是以一項主題為中心，向週圍發出旁支。思想的組織可能是很多主題詞彙彼此有許多連結關係，構成網絡形狀；心智圖則將主題限定為一項，而且組織形狀像樹(只有從一個上頭詞彙發出旁支、卻沒有幾個旁支會集)。目前，我這樣使用心智圖：

處理要點：例如，

。

整理考慮要素：例如，。

瀏覽程式結構：例如，

。

函數語言處理氣泡排序法

在碩士班期間擔任幾年的大學基礎程式設計課程的實習助教，在講台上解題，講了氣泡排序法幾乎有十次（對不同班、不同年級）。

for (i=0; i<N; i++)
        for (j=0; j<N-i-1; j++)
                if (A[j] > A[j+1]) {
                        temp = A[j];
                        A[j] = A[j+1];
                        A[j+1] = temp;
                }

二個迴圈洽好代表二層次的工作：裏層負責排列順序、外層負責控制執行次數和調整排序範圍。

用 Haskell 函數語言寫氣泡排序，是將二個層次功能做好，然後組合起來。首先是氣泡調整的部份（如下方的 bubble）， bubble 函數要將一列資料由小（左）排到大（右），而且要從右邊開始向左調整順序，將較小的數字往左邊推。這和上述的普通程式處理方向相反。

bubble :: (Ord a) => [a] -> [a]
bubble [x] = [x]
bubble (x:xs)
        | x > y = y:x:ys
        | otherwise = x:y:ys
        where (y:ys) = bubble xs

次數控制的部份（如下方的 loop）， loop 函數一方面要先將某個 f 函數套到一串數列（xs）上、取回的結果（y:ys）再將 f 函數套上去；另一方面， loop 函數控制執行次數，藉由將 f 函數再次套到上次已經套過 f 函數的結果（y:ys）時，是將第一個數字（y）取出，將 f 函數套在剩餘的數列（ys）上。每次套上 f 函數之後，就取出數列的一個數字，於是剩下的數列越來越小，直到剩下空數列（[]）。

loop :: (Ord a) => ([a] -> [a]) -> [a] -> [a]
loop f [] = []
loop f xs = y : loop f ys
        where (y:ys) = f xs

接下來，氣泡排序程式（如下方的 bubbleSort），是將 loop 函數和 bubble 函數放在一起。

bubbleSort :: (Ord a) => [a] -> [a]
bubbleSort = loop bubble

執行情況：

GHCi, version 6.8.3: http://www.haskell.org/ghc/  :? for help
Loading package base ... linking ... done.
Prelude> :load "d:/code/hsBubbleSort/bubbleSort.hs"
[1 of 1] Compiling Main             ( d:/code/hsBubbleSort/bubbleSort.hs, interpreted )
Ok, modules loaded: Main.
*Main> bubbleSort [3,2,9,7,8,5,4]
[2,3,4,5,7,8,9]
*Main> bubbleSort [5]
[5]
*Main> bubbleSort []
[]
*Main>

SOAP訊息的重用

SOAP是使用XML的通訊協議，傳遞的訊息有相當結構性質。而SOAP一般的缺點是，將程式物件的結構（圖結構或樹結構）拼合為訊息的線狀結構非常耗時。這種特性可以理解，例如 ASP 的 VBScript 字串連接符號 & ，與 Haskell 的字串附加運算符號 ++ ，都是惡名昭彰地拖延效率。

有研究指出， SOAP 所傳輸的訊息經常重複，因此只要將舊訊息多多重用，就能夠加強效率。考慮二則訊息的比對，結果是以下四種情況的其中一種：

1. 完全符合：內容直接符合。
2. 良好的符合：結構與長度符合，但資料有些不同。
3. 部份符合：結構符合，但長度和資料不同。
4. 不符合：結構不符合。

完全符合的訊息可 100% 重用，而不符合則必須照舊建立新訊息。而前後二訊息有資料和長度的若干不同，則可藉由將長度補足為相同，在將差異的局部加以修改，就能節省若干重建結構的時間。

程式細節上，要將一段 SOAP 訊息作大小幅度修改，有若干技巧如劃塊預存(chunking)、平移(shifting)與偷遞(steeling)等等，進而作聰明的編輯距離(editing distance)規劃，實作者必須多研究、演練並加強。

相關文獻

1. Suhyun Kim, Daeyoung Kim, Jongwoo Sung and Tomas Sanchez Lopez. Template based high performance ALE-TSOAP message communication. Fifth International Conference on Software Engineering Research, Management and Applications, pp.534-541, 2007.
2. Nayef Abu-Ghazaleh, Michael J. Lewis, Madhusudhan Govindaraju. Differential serialization for optimized SOAP performance. Proceedings of 13th International Symposium on High Performance Distributed Computing, pp.55-64, 2004.
3. Nayef Abu-Ghazaleh, Michael J. Lewis, Madhusudhan Govindaraju. Performance of dynamic resizing of message fields for differential serialization of SOAP messages. Proceedings of the International Symposium on Web Services and Applications, pp.783-789, 2004.