使用案例圖

使用案例(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, ... )表示巢狀的發生順序。

資訊系統分析與設計

系統分析師(System Analyst)
資訊系統(Information System, IS)可以蒐集、處理、儲存及散佈資訊，協助管理者進行經營決策、問題分析、重塑工作流程、控制作業、創新產品與服務。系統分析與設計(System Analysis And Design)是一門關於開發資訊系統的學問，其中系統分析牽涉到研究現在的系統，瞭解其運作模式及如何滿足使用者的需求，而系統設計是以系統分析的結果為基礎，改善現有的系統或開發新的系統。系統分析師的工作包括系統分析與系統設計兩個部份，他們會訪談不同的使用者和管理者，瞭解企業的運作模式及需求，然後提出並評估各種解決方案，供管理者選擇。

系統開發生命週期(System Development Life Cycle, SDLC)
系統開發生命週期雖然是相當古老的資訊系統建置方式，但目前仍常應用於中、大型系統，例如交易處理系統(TPS)、管理資訊系統(MIS)、這些系統的特點在於需求結構化，而且能夠事先定義規格。SDLC將系統建置過程分成下列五個階段：
一、系統調查(System Survey)：定義問題(本質、範圍與目標)、發掘機會、進行規劃及評估可行性，然後撰久專案企劃書。
二、系統分析(System Analysis)：蒐集與分析現有的系統，然後訂定新系統的需求。
三、系統設計(System Design)：完成新系統的邏輯設計，包括規格及運作模式，但不涉及程式設計。
四、系統開發(System Development)：完成新系統的程式設計，包括專案排程、撰寫程式及測試。
五、系統上線(System Implementation)：將現有的系統轉換成新的系統，包括系統轉換、檔案與資料庫轉換、設備轉換、教育訓練、安全稽核、系統評估、系統維護。
由於SDLC有固定的架構，而且在時程的安排上受到嚴格的限制，一定要一個階段接著一個階段的完成系統分析與設計的工作。因此，為了改善系統分析與設計的流程，有一些不同的方法被發展出來，其中最具代表性的包含雛型法、協合應用系統設計、CASE工具及快速應用系統開發。

雛型法(Prototyping)
雛型法乃是指分析師先與使用者溝通並決定系統所需最原始或最基本的需求，然後使用各種開發工具設計並建置一個較小規模但是可以操作的版本。當雛型建立完成後，使用者回報分析師滿意及不滿意的功能，分析師根據這些意見修正原先之雛型，然後再將較新的版本交給使用者使用。這樣的過程不斷的重複，直到使用者對所用系統滿意。

CASE(Computer-Aided Software engineering, 電腦輔助軟體工程)工具
CASE工具是一套以電腦為基礎的產品，針對軟體發展過程中的一個或多個活動來做必要的支援。CASE工具可以支援SDLC各階段的活動，也可以幫觔專案的辨識與選擇、專案的初始與規劃、分析與設計，也可用以幫助實作及維護。

協合應用系統設計(Joint Application Design, JAD)
JAD最基本的概念是將分析階的需求決定過程以及設計階段中的檢核過程加以結構化，使用者、管理人員及系統開發人員聚集在由JAD領導者所主持的密集性、結構化會議。JAD領導者任務在於確保會議過程的結構並掌握會議的議程，將有關資訊系統的人員聚集討論並確認系統需求及設計細節、時程與企業資源的應用，同時也讓所有參與人員能更快速了解系統的運作目標。

快速應用程式開發(Rapid Application Development, RAD)
RAD漸漸成為廣為接受的方法論是因為以網頁為基礎的系統(Web-based System)的快速開發。因此，結合雛型法、CASE工具以及JAD…等方法而成的RAD，可以大幅降低系統設計與實作時間。一般來說，RAD的過程與傳統的SDLC類似，但縮短或合併部分階段，並且運用各種工具，以產生更為精簡的開發技術。

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

物件導向技術(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的處理圖，用來說明系統各軟、硬體元件的配置、關聯，以及同一處理器內執行處理的時程安排等。

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

資料正規化

在講正規化之前必需先說明的是「功能相依」，假設一個學生資料表之中，學號的欄位值是唯一的，所以學號的欄位值決定了姓名的欄位值；我們就可以說姓名功能相依於學號，或者說學號功能相依姓名。

將表格細分成多個更小的表格，直到每個表格只描述一種事實為止，這一連串的調整過程就稱為資料正規化（Normalization）

正規化的目的何在？簡單的說就是要將資料的重覆性降至最低（避免資料重複的狀況發生）。倘若在不同的表格中都有學生的姓名時，一旦有個學生改名了，則必須 同步更改多個表格的內容；修改的過程中若稍有遺漏，有些資料沒更正，就會發生不一致的狀況。因此，避免資料重複是相當重要的。

一般來說，正規化的步驟分為四個
第一正規化(1NF)：每個一表格都會有一個 主鍵 ( Primary Key )，同時每一個表格 ( Table ) 中的每一列 ( Row ) 的每一欄 ( Column )，都只能存放單一的資料值。
第二正規化(2NF)：在表格中的每一個不是主鍵的欄位都只能與主鍵有功能相依性。
第三正規化(3NF)：在表格中的每一個不是主鍵的欄位都必須與完整的主鍵有功能相依性。
廣義第三正規化(BCNF)：如果主鍵為單一欄位時，就不需要考慮這個狀況了。但是當主鍵為複合欄位時，必須逐一檢視主鍵中每一個單獨的欄位是否與其他欄位有相依性的關係，如果有的話就必須進一步拆解表格。
每一步驟的正規化都是往下包含的，也就是說符合第三正規化也就一定符合第二正規化，也就一定符合第一正規化。

當然也是有人提出第四、五正規化，但是一般的資料庫設計並不需要用到那麼細緻的分割，有時甚至還需要反正規化，因此，就不詳細介紹第四、五正規化。