UML & Use case
本文重點在於UML的基本觀念介紹以及Use Case使用案例圖的說明；UML總共有多達十三種圖形，但其中最簡易且同時適合IT與非IT背景同仁學習的以Use Case莫屬，因此每位同仁其實都可以看懂甚至於自行繪製Use Case圖形。
我最近看了幾本UML相關書籍以及網路文章，並試著將當中Use Case的學習重點記錄下來，因此本文可以說是自己的Use Case學習筆記，在文章中我試著將這些重點再藉由自己的言語表達出來，希望能用一種很白話且簡單直接的方式，讓大家看過就能瞭解什麼是UML，並且能夠觀看並開始繪製基本的Use Case案例圖。
一）UML是什麼？
UML是Unified Modeling Language的縮寫，直接翻譯成中文就是「統一模組化語言」，所以，從字面上我們大致可以猜出，UML是一種語言、用來建構模型、而且是一種統一的標準；但是這個名稱看起來還是太深奧了，它為什麼需要冠上Modeling動詞和Unified這樣的形容詞？而且程式語言一般都有著其取向與目的，像古老的COBOL是商業設計專用的語言、BASH SHELL常用在Linux系統程式、Javascript大量運用於前端(使用者端)網頁，那麼UML是用來作什麼的？它可以寫出什麼樣的程式？
實際上，UML是一種具有特殊目的與用途的圖形化語言，它的「Language語言」是由各種形狀不一代表著不同功能的圖形組合而成，「Modeling模組化」則是指將腦海構思中的系統架構透過這些圖形表示出來，「Unified統一」指的是這些UML圖形和組合方式有著統一的標準規格，不同的開發者和使用者們都能理解並看得懂。
所以，你知道了嗎？UML是一套描述系統架構的語言，就像大樓的建築師們有一套標準的圖形與構圖設計方法，軟體系統也有類似的作法，就是UML，它的產出是一張張不同類型及目的的圖形，可以協助軟體開發者瞭解客戶的需求、讓客戶知道軟體開發人員所架構出的系統是否符合所需、也可以讓軟體開發團隊們在溝通協調彼此所進行的系統時更為順暢，所以，我們也可以這麼說，UML是一套客戶與開發者團隊之間共用的標準語言，它的功用就是加強開發者與客戶需求以及開發團隊彼此之間的瞭解，最終目的是加快軟體開發效率。
二）UML的類型
既然你已經知道了UML的用途，那麼，你可能也會懷疑它的產出是什麼？像PHP或ASP.NET是把程式碼放在網頁伺服器上執行嗎？還是像Ｃ一樣得經過Complier，或者甚至於跟JAVA一樣需要在一個虛擬機器的環境下才能執行？
其實都不是，正如在上段所提的，UML中的Modeling這個字，代表了它是一種將虛擬的軟體系統給模形化出來，讓你我都能瞭解這個系統的用途及目的，所以它是一種描述性語言，它最終的產出是一張張各式的圖表及流程圖，種類約有十三種，而我們可再將這些產出圖形依其特性再分為二大類，分別是Structure Diagram結構式圖形與Behavior Diagram行為式圖形。
- Structure Diagram結構式圖形
- Class Diagram類別圖
- Object Diagram物件圖
- Component Diagram元件圖
- Deployment Diagram佈署圖
- Package Diagram套件圖
- Composite Structure Diagram 組合結構圖
- Behavior Diagram行為式圖形
- Activity Diagram活動圖
- State Machine Diagram狀態機圖
- Sequence Diagram循序圖
- Communication Diagram 通訊圖
- Use Case Diagram時用案例圖
- Timing Diagram時序圖
- Interaction Overview Diagram 互動概觀圖
上述的結構圖和行為圖兩者最大的分野，在於前者描述的是系統的「靜態」的結構，例如使用元件、如何佈署等等，而後者描述的是系統內「動態」的行為，像是流程、過程、互動等。看到了UML有這麼多類型的圖表，你會不會心裏一驚後悔正準備要一探UML的領域？但其實在這些UML圖形中，經常使用的只有下面六種：
- Structure Diagram結構式圖形
- Class Diagram類別圖 經常使用，可表達系統的靜態結構，但是需要 物件導向分析的能力
- Component Diagram元件圖
- Deployment Diagram佈署圖 → 經常使用，元件圖與佈署圖多用於分析IT基礎架構、軟體架構等，但是需要具備IT相關的Knowhow
- Behavior Diagram行為式圖形
- Activity Diagram活動圖
- Sequence Diagram循序圖 經常使用，可用於表達系統的動態行為；活動圖類似流程圖的概念，因此很容易掌握製作方法，且適用於大部份的業務流程分析；其最大的優點則在於能夠清晰的表達過程中所參與的角色、角色之間的關係、以及各角色是如何參與)
- Use Case Diagram使用案例圖 → 經常使用，可表現該系統的對外功能是什麼；我們透過使用案例圖可表達出是什麼角色透過系統來作什麼事情，大部份都將此圖用於說明並表達使用者/系統的絕大部份需求。
而在這經常使用的四種圖形當中，使用案例圖、類別圖和循序圖這三者的重要性排名前三大。因此我們只要學習並透過這三種圖形，便可以很快的呈現資訊系統的對外功能、靜態結構和動態行為。
三）需求分析
介紹完了UML的基本概念，那我們可以直接開始學習如何製作UML圖形了嗎？先別急，你知道為什麼需要畫這個UML圖嗎？是不是要規劃並製作一套系統？那麼又為什麼要製作這套統，應該不是沒事找事作，而是來自使用者的需求吧？而既然這是一套使用者需要的系統，那麼，我們就必須提醒自己，釐清使用者並且確切滿足使用者的需要對於手上這件正要開發的系統是一件事非常重要的事，我們千萬不可以一開始就肓目的埋頭苦幹，否則最終下場肯定是如同下方的圖形一樣：不符使用者真正需求且糾紛不斷。
重點1：瞭解使用者的需求是持續進化的
事實上，需求分析可能是整個系統開發過程中最困難的一個階段，它遠比我們正要學習的UML更具挑戰與不確定性，主要原因是：
- 需求分析必須從事大量的溝通工作
- 用戶對系統的需求經常敘述不清
- 缺乏自動化工具支援
- 使用者需求經常隨時間或想法而改變
由於上述這些因素，導致使用者需求經常在變動，使得開發者也因無可遵循而導致最終產品不符使用者真正的需求；但其實我們只要把握一個原則，就是認知到雖然使用者的想法總是在變化，但整體而言這種需求變化是呈現螺旋前進的，這樣的需求變化是一種持續進化的現象，因此我們不應對此有任何的抱怨。
此外，系統開發期間的使用者需求變更其實並不是壞事，說明了使用者對於自己的需求有了更進一步的瞭解，而開發人員若對此需求變動會感到不適應，反而代表了他們對於需求瞭解的進步程度不如使用者。
重點2：系統持續產生問題其實是一種良性的現象
假設某系統已經上線了，出現以下三種情況，你會更喜歡那一種情況呢？
- 使用者一直沒有提出過任何問題。
- 使用者開始提了一些問題，但很快就沒有其它問題了。
- 客戶一直在提問題，開發人員解決了這些問題後，新的問題又來了，如此不斷重複。
我們先看看A現象，這代表使用者幾乎或很少在使用這套系統，所以沒有提出什麼問題。
再來是B現象，有兩種可能，第一種是使用者在試用一段時間後，由於某些原因而不再使用該系統了；第二種可能，是使用者曾經提出過很多問題，但開發人員無法順利的解決這些問題，因此最終使用者乾脆不再使用了。
而最後的C現象可能是很多開發人員與使用者經常碰到也最討厭的現象，因為每天都會發現新的小問題或者被這些小問題所糾纏，但其實這是相當理想的良性狀況，代表了使用者持續的在使用該系統，因此問題一開始會比較多，而開發人員一開始的問題解決速度也低於問題的產生速度，但持續到後來，問題會逐漸減少直到完全消失。
重點3： UML可協助進行使用者需求分析
開發人員經常只看到使用者所開出的「需求規格」，並且往往僅侷限在這個層面進行各項的系統開發工作，但事實上，所謂的「需求規格」代表的是使用者一種很表面的需求要項，它其實並不是使用者的「需要」，使用者的需要是必須透過挖掘與分析而得到的，真正的需求分析是能夠「透視」這些表面的「需求規格」而挖掘出使用者的需要，而UML這個工具就可以協助進行「透視」的工作。
那麼UML如何協助進行「透視」的工作呢？原因就在於它可以：
- 弄清楚系統的目標和範圍
- 找出系統的所有關鍵人物，並列出所有解決的問題
- 分析業務，確認問題，發掘真正的問題
- 針對問題，提出系統的特性
- 針對特性，提出系統的用例，並細化功能需求和非功能需求
而UML的兩大類圖形：結構圖與行為圖就是協助上述的問題而產生的，透過這些圖形可讓開發人員更進一步的瞭解使用者業務以及業務流程，以及瞭解並挖掘使用者的需求。
重點4： 利用UML來協助使用者發掘需求
下圖是一種很常見的狀況，它表示了一個正在開發中的系統，隨著時間發展，使用者和開發人員對於需求瞭解程度的上升趨勢；在時間=0時，使用者對於需求是有一定認知的，所以會有該系統的需求產生，所以並不是從零開始，而開發人員對該系統的需求瞭解一開始就不如使用者。
隨著時間的發展，雙方對於需求的瞭解愈來愈強，但開發人員對需求的認識總是落後於使用者，這樣的現象造成整體系統的開發工作陷於被使用者牽著走的被動局面，且雙方很容易產生相互責怪的現象（使用者責怪開發人員水準太差，開發人員責怪使用者的需求變來變去）。
要打破這現象，開發人員必須能夠做到如下圖的效果：比使用者更瞭解系統的需求，並引領他們挖掘真正的需求，如此，才能開發出真正符合使用者所需的系統。
四）Usecase diagram使用案例圖的目的
一般初接觸UML的系統開發人員對於使用案例圖並不習慣，甚至於沒有好感或嗤之以鼻，因為那看起來只是幾個幾何圖形配上個小人，外加少許的文字與箭頭這麼簡單的流程圖形，和系統開發者素來以功能面為出發點的系統流程圖差異甚大，使得很多人懷疑這樣的案例圖真的能改善工作嗎？使用它的真正目的到底是什麼？
對於系統開發者來說，「使用案例圖」最主要的功用是轉變思考的角度！
舉個例子來說，如果我們打算做個考勤系統，傳統上我們會先怎麼思考呢？我們是不是先想到要用什麼語言開發？可以使用什麼Database？需要提供那些功能？可能會使用到那些子系統？每項功能的流程和其它系統的關聯？... 你有沒有發覺我們都是從功能面為出發點來構思整個系統？
但是比較好的方式，應該是從人的角度來思考，什麼人會使用這個系統？然後逐一思考不同的人對系統有什麼需求。所以，首先我們可以估計到一般員工、主層主管、總機、財務等都會用這個系統：
- 對於一般員工來說，除了打卡之外，他還關心什麼？
- 高層主管使用這個系統的目的是不是想檢視大家的出勤狀況？
- 對於總機來說，她是不是需要做一些考勤的統計？
- 財務人員是不是要根據考勤情況來調整員工薪金？
有沒有發覺，透過這樣的思考方式，會讓我們更容易全面發掘系統的需求？
在「使用案例圖」中，人就是角色，當我們思考某系統的需求時，「使用案例圖」就給予我們啟示，告訴我們可從不同角色的角度來思考，因此，其實「使用案例圖」的最終目的是：
Ａ）讓雙方有共通的語言：「使用案例圖」的特點主要在於：
- 清晰扼要的描述系統行為。
- 不涉及專業術語或技術議題。
- 讓使用者與開發者雙方都能看得懂並確認需求目的
Ｂ）「使用案例圖」可以回答：
- 這個系統有誰在用？
- 這些人透過系統能夠做什麼事？
五）開始使用「使用案例圖」
在對於UML有了基本的認識，並瞭解了「使用案例圖」的功能與目的後，下面我們可以開始來學習如何繪製「使用案例圖」了。
Ａ）繪製原則
邱郁惠小姐是目前產業界相當知名的UML實務專家，她寫過相當多的UML相關書籍，也開過很多的訓練課程，在「SA前進UML專案現場」一書中，她提到IKEA創辦人Ingvar Kamprad常把「簡單是一種美德」這句話掛在嘴邊，Ingvar Kamprad經常訓誡大家，只有平庸的人，才會提出複雜的解決方案。
同樣的，邱小姐受其影響在UML的傳授上也是提倡極簡的風格，她認為保持簡單使用UML是一項值得讚許的美德，只有平庸的團隊，才會把UML用得既複雜又困難，因此要求開發團隊成員應使用最少量的UML概念和圖示才能減少習習與溝通成本，以加快開發的步調。
我本人也頗為讚同這種精簡的理念（當然囉，能夠少學一點何樂而不為呢？）因此，雖然UML的每種圖形都包含有數十種的圖示，在下面我將僅介紹四種圖示，實際上只要使用這四種圖示，便可應付所有的場合了。
Ｂ）使用案例圖示介紹
1. Actor
此圖為大字上面君個圓圈，就像一個人形狀，英文名稱Actor，中文直接翻譯的話是演員、行動者的意思，一般在國內的UML書籍則解釋為「執行者」或「參與者」
當我們針對某系統的使用者進行分類後，可以整理出該系統擁有哪幾種角色，不同的角色有不同的工作責任，所以他們需要使用的系統功能也會不一樣；利用角色的觀點，給予了我們一個啟示，當我們思考某系統的需求時，可以從不同角色的角度來思考。
在繪製時，我們需要注意，角色這個圖形可以代表多個實際的人，而且同一個人也可以扮演多個不同的角色，因此實際應用時，我們通常會將某些職位或部門抽象為角色，但有的時候，這個角色也可能不是由人或職務扮演，而是另外一個系統，因為該系統會去與另一個系統互動，所以這種情況下，我們可將另一個系統畫為執行者。
2. Use Case
Use Case字面翻譯是「使用案例」，它代表的是系統的各項功能，也就是這個系統能夠作什麼事情。
請注意，在UML使用案例圖中的所謂Use Case，一定要能表達出"動詞+名詞"這樣的結構，例如，"觀看影片"、"查看自己的考勤記錄"、"登入系統"...等等，這樣一個動詞結合名詞的語句才能算是一個完整的Use Case情況，之後我們才可以將此Use Case連到某個會與其產生互動的角色上。
要檢視使用案例圖畫得是否合適，我們可以按此順序來讀這個圖：先讀出執行者的名字，然後讀出使用案例中的文字；按照這樣的讀法，我們可以得到兩個完整的句子：
- 一般員工觀看創新TV節目
- 一般員工推薦創新TV節目
如此才是一個完整的使用案例；另外要注意的是，一個使用案例不一定只能連到一個執行者，它也可以同時連到多個不同的執行者，這代表某個功能是被多個使用者所使用。
3. Association
我們使用線條將角色與使用案例連接起來，代表某某執行者能夠執行什麼使用案例，因此該直線代表的是兩者之間的關聯。
一般我們會使用三種直線：無箭頭的、指向用案例的、指向執行者這三種，而當中的箭頭代表的意義可以是下列其中一種：
- "資料流向"：指執行者與使用案例的互動過程中資料的流向，如果箭頭指向使用案例，就說明使用者需向系統輸入資料，如果箭頭指向執行者，則說明系統輸出資料給執行者，而沒有箭頭的線條，代表沒有明確的資料流向。
例：系統B輸出資料給系統B
- "誰啟動誰"：當箭頭由執行者指向使用案例，則表示由使用者啟動系統，這是大部份的情況；有極少的情況是由使用案例指向執行者，代表的意思是指系統導出資料到系統B（系統B為執行者）。
例：系統A啟動"從系統A導入資料"的使用案例
由於箭頭本身及方向代表了不同的意義，若沒有加上額外說明或其它文件（例如：使用案例表）的輔助，可能會增加雙方認知的麻煩，因此，有部份的UML專家建議並不一定要非要畫出箭頭，因為使用案例中已經有定義出"動詞"了，只要繪出的案例圖能夠讓人瞭解，有沒有箭頭並不是那麼重要。
4. Include & extend
與上述的使用於執行者和使用案例之間的"Association"不同，Include（包含）與Extend（延伸）代表的是使用案例之間的關係。
4.1 Include
從上圖我們可以看到，"管理預設節目"這個使用案例包含了四個子使用案例，分別是"增加",修改"刪除","瀏覽","刪除"（此四種功能在MIS有一個術語稱為CRUD：Create/Read/Update/Delete）。
我們把這四個案例抽離出來成為Include的子案例，好處在於它可以同時被其它的案例所使用，例如"增加","瀏覽","刪除"這三個功能可被一般員工的"點播"功能使用，所以此三個案例亦成為"點播"的子案例，我們可以畫成如下的圖表：
4.2 Extend
Extend有延伸、擴充之意，我們可以把它看成在某使用案例的基礎上，還能做什麼事情；箭頭的方向表示誰擴充了誰。我們先看看下方的圖表：
上圖表示一般員工可以在觀看創新TV節目的時候進行"推薦"或"轉寄"該節目的功能，換句話說，也就是一般員工在觀看創新TV節目的基礎上可以選擇"推薦"和"轉寄"。
4.3 Include & Extend
另外我們必須注意到的一個重點是，Extend和Include除了箭頭方向相反之外，它們之間有一個很大的差異是：對於Include來說，若缺少了任一個子使用案例會不完整，亦即對母案例來說，所有的include子案例都是必要的、缺一不可的，以上述Include說明中的例子"管理預設節目"來說，"增加",修改"刪除","瀏覽","刪除"這四個功能是管理節目表的必要項目，缺一不可，少了任何一個都無法達到"管理預設節目"的目的。
但是對於使用Extend的母案例來說，子案例並不是必要而是選擇性的，也就是說，若沒有了"推薦"或"轉寄"功能，一般員工還是能夠執行觀看創新TV，但有了的話可能會更好甚至可以增加使用者體驗。
4.4 Extend & UX
Include和Extend其實不難理解，相信你讀過便能馬上領會，此外，你有沒有發現到，其實Extend的設計與良好的使用者體驗有著密切的關係哦！
如果我們把上面的"觀看創新TV"的例子改成如下，那麼使用者體驗會變成如何？變成員工看到一部不錯的節目，他必須另外回到主畫面上，點選推薦或轉寄的按鈕，再從一串節目單中選擇剛剛想要推薦的那個節目，這樣使用者體驗是不是很差？因此一個好的案例關係設計，通常能給使用者帶來更好的使用者體驗。
六）最後
除了上述的這四種圖，其實還有其它的圖例像是繼承（Inheritance）與系統邊界（System Boundary）等我並沒有介紹，首先，並不是所有的案例圖都需要畫出系統邊界，如果在每個使用案例圖的案例中都畫出系統邊界將會顯得很累贅，我們只要在最外層的使用案例圖畫出系統邊界就可以了。另外在繼承圖例的使用上，"繼承"這個概念對於非IT背景的同仁來說經常比較難以理解，尤其它很容易與Include及Extend造成混淆，因為那個被繼承的父使用案例，往往是一個抽象、無法被實際執行的使用案例，它必須被繼承後才能夠由使用者來執行，對於沒有軟體開發經驗和物件導向設計經驗的同仁和使用者來說，要去理解這種"抽象類別"會有些困難。
在本文中，我大致介紹了UML及UML圖形Use Case（使用案例圖）的繪製，並以創新TV為範例示範怎麼使用其中最常用的四種圖例，相信您只要利用這四個圖例便可看懂UML並應付部份的系統開發需求了。你要試看看瞭解多少了嗎？下圖是我在網路上找到的一個網路訂書的Use Case，僅用到本文所介紹的四種基本圖例，請試看看是否能夠領略。
沒有留言:
張貼留言