使用案例圖

使用案例(use case)

使用案例(use case)可以展示系統功能或系統行為。使用案例是描述系統與使用者在特定情境與目標下的一系列互動行為。使用案例描述在不同的情境下，系統針對行為者要 求的回應。行為者對系統提出達成特定目標的需求，系統再根據要求回應行為者。使用案例的名稱可為現在式時態的動詞片語，包含動詞(系統應該做什麼)與動詞 的受詞(系統應該對哪一個對象進行操作)。

使用案例圖(use case diagram)

使用案例圖是UML最常用的三種圖之一，許多專家認為，如果把UML 2 的13款圖簡化一下，大概只會剩下3種圖，使用案例圖就是其中之一，而另外兩款則是類別圖以及循序圖。使用案例通常用來表達系統的功能觀，它的組成元素很 簡單，就是「使用案例」（use case）、行為者（actor）和兩者之間的關係線。簡單來說，使用案例代表系統對外提供的服務或功能，而參與者則是位於系統外部，會直接接觸系統並啟 動使用案例的使用者，或者是支援使用案例的其他連線系統。建構使用案例圖的步驟依序為：找出行為者、找出使用案例、描述使用案例、找出使用案例的關係，最 後繪出使用案例圖。

找出行為者

行為者可以從使用者與企業需求描述中的名詞、代名詞與名詞片語等，找出合乎行為者定義的人、組織或相關系統。

找出使用案例

許多專家建議，由行為者找出使用案例是一個有效的途徑。也就是說，先找出行為者，再逐一檢討行為者以找出其所參與的每一個使用案例，之後會有相關事 件的回應，直到完成使用系統的目的為止，將這一系列事件有組織的集合起來便成為一個使用案例，但這些事件間必須符合內聚力的原則。

描述使用個案

一個完整的使用個案內容應包括行為者、使用個案目標、使用個案發生之前提與結束狀態、一系統事件描述等。使用個案描述是從使用者的觀點，描述使用者 欲達成某項目標或功能的作業行為，此時應著重企業的作業處理或功能描述，而不應涉及電腦化的程式邏輯；一系列事件的描述除了正常程序外，最好也能包括例外 狀況的描述。

找出使用案例間的關係

使用案例間的關係主要可以分為三種：Include、Extend和Generalixation。Include可視為某一使用案例「A」會用到 另一個使用案例「B」，關係的箭頭符號應由A指向B。Extend的關係可視為是某個使用案例(例如 A )在某情況時會被插入至另一個使用案例的定義中(例如 B )，而形成一新的組合使用案例，則關係箭頭符號應由A指向B。Generalization的關係意味著使用案例間的繼承關係，例如子使用案例會繼承父使 用案例的行為與意義，且子使用案例可擁有其個別的行為與意義。

繪製使用案例圖

完成上述工作後，最後是繪製使用案例圖。繪製步驟為先繪出所有行為者與使用案例，將行為者與使用案例間有互動者以互動符號連結，接著再確定使用案例間的關係，並以適當的關係符號連結。

循序圖 & 合作圖

物件導向系統的資料結構塑模主要以類別圖與物件圖表達物件間的靜態資料結構；而物件互動行為則主要以互動圖來表達物件間動態的互動行為。互動圖包含循序圖與合作圖，一個互動圖描述一個使用個案內物件間的互動行為。其中，循序圖著重以時間發生的先後順序來表達物件間的訊息傳遞與與處理之程序；而合作圖則著重表達物件間的連結結構，並能同時展現物件間的訊息傳遞與處理之程序。

循序圖(Sequence Diagram)
循序圖主要用於描述許多物件在單一使用個案中的互動行為，但不太適合用於對這些行為的精準定義(較精準的定義用狀態圖或活動圖來描述為佳)。循序圖強調以時間發生的先後順序表達物件間的訊息傳遞與處理程序，其重要元件包括類別的物件、訊息、操作與操作描述要生命線與控制焦點等。


物件
如果尚未建構類別圖，而先建構循序圖，循序圖上物件之確認準則與類別圖相同；如果先完成類別圖，再建構循序圖，則循序圖的物件可以直接用類別圖上類別之物件，其表達方式是在類別的名稱下劃一底線。原則上，循序圖的物件是放置在循序圖的上方。

訊息
循序圖的訊息(Message)或刺激(Stimuli)是由某一物件送至另一物件以啟動操作。一般來說，訊息常需與操作相結合。在循序圖中，訊息是以水平的箭頭表示，而且箭頭起始於傳送訊息的區域(也就是控制焦點)，終止於接受訊息的區域。大部份的循序圖都由一個來自於系統外部的訊息所啟動。

操作與操作描述
循序圖的操作(Operation)在於描述循序圖中，某一物件接到另一物件送達的訊息，接收端的物件為了執行發送端物件送來的要求，所提供因應處理該訊息的方法。操作描述是操作的細部詳細說明，主要是從系統行為的觀點，描述系統的動作與邏輯順序所需的輸入與輸出。操作描述是往後程式設計的重要依據，程式編輯完成後，這些操作描述可作為程式的註解。

生命線
循序圖的生命線(Lifeline)是劃在物件底下與物件重直的虛線，用來表達物件在某時段的存在。

控制焦點
循序圖的控制焦點(Focus of Control)表達物件執行某動作的時段，包括由其執行或透過其附屬程式。控制焦點用長條圖表示，且與該物件的生命線重疊。

合作圖(Collaboration Diagram)
合作圖主要用來描述許多物件在單一使用個案中的互動行為，和循序圖一樣，不太適合用於描述這些行為的精準定義。但合作圖強調以物件的結構化組織表達物件間的訊息傳送/接收與處理程序。合作圖的重要元件包括類別的物件、連結、訊息與操作等。


物件
合作圖的物件與循序圖的物件相同，都是來自於類別圖上類別的物件，或直接由使用個案圖描述找出，其表達方式是在類別的名稱下劃一底線。

連結
合作圖的連結(Link)是用於表示一個物件如何與另一個物件連接，以直線來表示。合作圖上的連結也就是物件間的路徑(Path)。

訊息
合作圖的訊息(Message)包含兩物件間的訊息傳送/接收內容與操作，並且將這些訊息伴隨著一個箭頭來表示。訊息的發生順序可在訊息前面加一個序號來表示，在合作圖中這些序號都是唯一的。序號以自然數(1, 2, 3 ...)表示其發生順序；也可以用杜威數( Dewey Decimal Numbering, 1.1, 1.2, 1.3, ... )表示巢狀的發生順序。

物件導向技術的系統分析與設計

物件導向技術(Object-Oriented Technique)是繼結構化技術之後，系統開發上另一受到高度重視的新思維，已經成為軟體工程領域的熱門議題。物件導向的基本概念包括物件、類別、封裝、繼承、同名異式與超荷等，其中的物件、類別、繼承已經在之前的PHP程式設計概念中提到，本篇將針對封裝、同名異式與超荷做簡單的說明。另外，系統開發的相關工作，統一塑模語言，包括使用個案圖、類別圖、循序圖等九種。

封裝(Encapsulation)
物件導向技術將資料及操作此資料的方法包裝成一個物件，稱之為「封裝」。封裝所形成的物件，其結構可分為兩部分：一是定義物件外觀行為的介面(Interface)部份；另一則是存放抽象化的結果及如何達成外觀行為的實作(Implementation)部份。封裝將物件的實作細節隱藏，使其與外界環境隔離，而只允許該物件所包含之操作修改其資訊，稱為資訊隱藏(Information Hiding)。封裝使物件更具獨立性，如果物件內部的資料結構有變動時，只要其外部的操作介面沒有修改，使用這些物件的應用程式就可以不必修改，這樣的特性使得物件導向的系統較容易維護。

同名異式(Polymorphism)
Polymorphism意指「多種型式」，簡稱「多型」，即在不同的物件(或類別)中，利用相同名稱的操作，以不同的方式處理資料，傳送訊息的物件不需要知道接受訊息所屬的類別，接受訊息的物件可以屬於任一類別。例如：某公司計算員工薪水，員工可分為正式員工及臨時員工，而臨時員工又可分為按件計酬與按時計酬，這三種員工都有薪資計算，但是薪資計算的操作又有不同計算方式。

超荷(Overload)
超荷就是在同一個類別中，使用相同名稱的操作，然而每個操作的參數個數、參數資料類型不可完全相同。當使用到此操作時，可以參數個數及參數資料型態的不同來判斷要使用哪一個操作。超荷有時又稱靜態多型。

統一塑模語言(Unified Modeling Language, UML)
統一塑模語言是Rational公司整合Booch、Rumbaugh與Jacobson三種方法而提出的物件導向塑模工具，是一種視覺化(Visualizing)、文件化(Documenting)及規格化(Specifying)的軟體塑模語言，經過不斷地演變與擴充，於2003年6月正式通過UML 2.0標準。在UML 2.0中規範了十三種模式圖，而其中使用個案圖、類別圖、物件圖、循序圖、合作圖、狀態圖、活動圖、元件圖、部署圖等九種較常用於商用資訊系統之分析與設計上。

使用個案圖(Use Case Diagram)
UML的使用個案圖是引用Jacobson方法中的使用個案模式，從使用者的觀點描述系統的行為者與系統間的互動行為與關係。從內部觀點來看，使用個案可描述系統做什麼(What)。從外部觀點來看，它可描述行為者與系統如何互動(How)。

類別圖(Class Diagram)
UML之類別圖是引用Booch與Rumbaugh方法中的類別圖，主要用以表示系統存在之物件型態(類別)及各物件型態間的靜態資料結構與邏輯關係，也表達類別之屬性、操作與類別間連結之限制等。

物件圖(Object Diagram)
UML的物件圖是用來描述一系統於某一時間的靜態資料結構，該圖由一群相關的物件及其連結所組成。物件圖是系統在某個時間點的一個例子，而非系統的定義，可用來表達一個系統複雜的資料結構，或藉由時間序列的系統影像(Snapshots)來表達系統的行為。

循序圖(Sequence Diagram)
UML的循序圖是結合Booch的互動圖與Rumbaugh的訊息追蹤圖而成，主要用以描述系統運作時物件間的互動行為，著重以時間的先後順序為主軸，以表達物件間的訊息傳遞與處理程序。一個循序圖會有一個與之對應的合作圖，但表達的重點與方式不同。

合作圖(Collaboration Diagram)
UML的合作圖是從Booch的物件互動圖與Rumbaugh的物件導向資料流程圖改進而成，主要用以描述系統運作時物件間的互動行為，該圖著重表達相關物件間的連結結構，並能同時展現物件間的訊息傳遞活動。

狀態圖(State Diagram)
UML的狀態圖是結合Booch的狀態轉移圖與Rumbaugh的動態模式而成，用以表示物件在其生命週期中的狀態變化。狀態圖是以微觀物件為主，細分物件所發生的各項事件，並表達物件生命週期之狀態轉變及活動結果。

活動圖(Activity Diagram)
UML的活動圖可用於表達執行某一作業行為中的活動、轉換與條件等。一個活動圖描述一群循序與同步的活動，一個活動可表示一個工作流程步驟或一個運算的執行動作。

元件圖(Component Diagram)
UML的元件圖起源於Booch的模組圖，用以說明系統設計過程各類別與物件的配置，以及敘述軟體元件間的組織架構和關係。元件是開發和執行過程中實際物件的類別，將可分解的實際基本單位模組化，這些基本單位包括模組(Module)，並擁有特性和明確定義的介面。

部署圖(Deployment Diagram)
UML的部署圖起源於Booch的處理圖，用來說明系統各軟、硬體元件的配置、關聯，以及同一處理器內執行處理的時程安排等。

物件導向系統開發過程是一種反覆的程序，主要包括需求分析、系統分析與設計、細部設計、程式編寫、測試與部署等階段。物件導向塑模提供了使用個案觀點、設計觀點、流程觀點、實施觀點與部署觀點等，可供不同參與者，在不同時間，從不同的角度來看系統。由於物件導向技術的引進，提升了程式的重用性與可維護性，使軟體的開發與維護更有效率。