B24 程式執行時直接操作資料

2007年初時部門進來三位新人由我先給予基礎的訓練。某一天我安排了讓他們寫一個程式讀取XML檔案的內容並依序把每個Node名稱一行，每個Attribute的name與value都放一行集中到最後儲存為一個文字檔。

果然如同預期那樣，第一次使用XML DOM的人都認為這已經把檔案內容物件化，因而在程式的處理過程中直接操作；輸出的部分則使用一個StringBuffer收集所有的輸出後一次把字串寫回檔案中；而且所有的程式都集中在一個Class裡。以這次提出的程式需求來說，全部的人都成功做出符合功能的程式。

接著我對他們說，現在客戶的資料因為系統升級改成從純文字檔輸入，你們要如何改變程式？再來，讀到的內容在轉出為文字檔前，客戶希望可以出現一個Table逐筆顯示所有的內容確認後再行存檔，這又要怎麼改呢？以現在的設計方式，會不會改到死？他們想了想後全都點頭。

Data Model的存在就是在預防未來資料的存取方式改變時，不會造成資料物件的改變進而影響其他使用資料的程式跟著要變更。我也不大贊同使用SQL代號找出SQL Command來存取資料庫而把資料放在兩維陣列物件的方式，雖然在開發時可以有較快的開發速度也較容易測試，可是在資料庫定義有改變的時候沒有Data Model居中緩衝，結果造成需要改變的功能必須另外做出一套類似機制的結果。

為了開發時的快速，面對重大的改變時無法將差異融入到先前的設計而必須另外拉出成一套機制，其至更多。如果設計的人面對這樣的情況時，會有想從一開始就改變的想法嗎？

B23 決定資料模組的儲存方式

資料模組的運用不外乎兩個方式：對外部系統的傳送與接收或自行管理資料的儲存與讀取。意義在於當系統關閉，記憶體內的資料完全消失後，還能從特定的地方獲得某個時間點的運行資訊並予以復原系統之狀態。

資料儲存的方式有兩個思考的重點。首先是方法，系統設計之初就要決定資料存取的方式，我們必須依照需求提到的內容判斷資料應用是傳給外部系統還是自行管理。傳送時要考慮傳送的方式、通訊協定等；自行管理時要考慮儲存的環境、方法等等。

再來是格式，儲存的資料要以什麼樣的格式放到儲存的地方，要如何讀回並復原成資料模組的物件是考慮的重點。不同的儲存方法會有不同的定義格式，一個系統也可能要對應多種不同的儲存方法；像銀行人員使用的系統幾乎都需要與主機通訊、存取資料庫、存取檔案，有時還要允許從網路連線操作系統、使用Web Service等等。

資料是系統內所有功能都需要操作的對象，也就是屬於最底層的設計。如果資料模組做得不好，在系統開發到一定程度時才發現需要修改，那麼就需要跟著修改一大串使用資料的程式。根基需要打好，才有法子令系統順序架在上面開發；“查埔人身體哪顧厚勇，家庭自然就會幸福”講的正是這樣的道理呢。

資料模組的設計，絕對不能忘記未來的擴充性。


◎系統的目標

B22 資料模組（Data Model）的建立

系統詞彙表建立好之後，我們可以應用CRC Card的方式來篩選所有名詞之間的關聯來決定其從屬關係。CRC這三個字母代表的意義為：Class, Responsibility, Collaboration，也就是本身、責任與合作，恰好可以對應到是（is）、擁有（has）、使用（use）這三個物件的關聯。

在這個步驟，我們將應用CRC Card方法從需求文件裡找出適合作為資料物件的名詞並命名（Class），並進而找出該物件必須記得的所有特性（Responsibility），以及自己不需要記得但是在特定時候會使用到的其他物件（Collaboration）。記錄下這些物件的內容與關聯，就會形成系統所需要的Data Model。

在現實生活裡與一個物件的相關的特性及其他物件實在太多了，但是我們只需著眼於系統所需要的特性。比如說一個人會的程式語言與頭髮顏色都屬於那個人的特性，但是今天公司的職缺需要會某種程式的人，那麼在徵人的需求裡就不會使用到頭髮顏色，人這個class就只需要記得程式語言即可。

收集好的Data Model最後還要進行最佳化的動作，比如消除多對多的關係，消除關聯物件等等的步驟。大多數的系統資料都會儲存在資料庫裡，最佳化後的系統Data Model可以作為資料庫表格設計的最佳參考資料；即使資料儲存在檔案裡，也可以依設計把資料內容分開存放，便利於管理。

B21 做人的方法(1)──記得該記的

物件的關聯通常有三個類型：是（is）、擁有（has）、使用（use）。

是（is）：定義出物件本身的種類。當一個男人說出“我是男人”時表示他即使做出一個男人應有的行徑；高志航在電影裡說“身為中華民國空軍，怎能讓敵人的飛機在我的頭上飛”時表示他將做出符合中華民國空軍的行為。是（is）在OO裡表達的是extends，描述物件具有父物件的全部特性與行為。

擁有（has）：定義出物件內部所有的特性。車子的顏色、油箱容量、乘坐人數、出廠年份等等的描述，都是車子這個物件的特性。特性也是名詞，只是它們附屬於車子這個名詞之內。擁有（has）在OO裡表達的是物件之內必須管理的其他物件。

使用（use）：定義物件在動作之中使用到不屬於自己的其他物件。如果你要從台北搭車往台中，執行這個動作的車通常是別人的，屬於別人的物件只有在該項行為裡才會暫時使用，自己並不需要持續記得別人的物件；要注意的是，如果要使用自己的車則需先取得自己的車再讓該行為使用自己的車子。使用（use）是描述其他物件只有在物件執行特定的行為時才會使用的這種關係。

物件屬於什麼樣的類型就應具有該類型一切定義特性與行為，記得自己應該記得的特性內容，記得做某些行為時需要使用哪些別的物件，視需要的狀況把其他物件記下來。每個物件都記下自己應該記得的物件，每個物件也被該記得的物件記著；每有物件各守其份時，任何物件的存在就都可以被追蹤出來並取得。

B20 建立系統詞彙表

既然Model是獨立的資料，系統又必須依據Model來設計功能。那我們要怎樣找出適合系統使用的Model呢？

現在我們已經收集並分析過需求的資料，並將功能需求存放在SRS裡。Model既然是靜態的，那表示我們可以從靜態的名詞取得類似的意義。因此在需求收集與分析的同時就應該開始收集需求裡使用到的名詞，來源主要會出自於Use Case描述與Use Case Scenario。

收集下來的名詞同樣需要分析，明顯與系統無關的名詞則予以捨棄，留下的每個名詞都需要用文字說明其意義。名詞同義字如有多個時必須選一個作為代表以避免未來使用時發生混淆。詞彙表主要是用來定義系統最基本的資料模組，同時也限定在溝通與文件上使用名詞都統一依照定義。

在收集需求的同時，系統詞彙表的內容就陸續依照需求中出現的名詞加以擴編並整理。等到需求分析接近一個段落（像訪談完一個子系統就可以）時，就可以開始著手設計系統的資料模組。

B19 執行系統是為了處理資料

電腦應用程式無法計算有多少類型，但是終歸一句話：程式的目的是用來處理使用者想要操作的資料。

舉例來說，使用Word的目的是要產生排版的文件，使用PowerPoint是為了製作投影片，PhotoShop是為了讓使用者做出漂亮的圖檔，線上購物是讓使用者找到喜歡的物品並下單購買。文件、投影片、圖檔、商品、訂單，這些靜態的物件都是資料。

MVC的概念目前廣被接受。靜態的處理資料稱作Model，將靜態資料以各種適當的方式呈現在使用者面前並接受使用者改變的是View，依照使用者的想法取得Model呈現在View、把View上使用者的變動回存到Model的責任則落在Controller的身上。Model-View-Controller的概念讓系統的設計有了分層分工的想法。

在責任上，View是用來顯示Model內容，Controller用來存取Model的內容，在使用的關係上來說View與Controller都必須有Model存在之後才能知道自己要如何操作Model。Model的來源是存在於系統外的，它應該是獨立且不受其他因素影響的，通常存在於檔案、資料庫或其他系統裡；系統只是為了使用Model而開發出來的。

B18 需求階段的模型（Model）與應產出文件

在需求階段裡，藉由訪談客戶獲取系統需求加以分析並記錄。記錄下來的物件關係模型如下面附圖。圖中物件間的關係如下：與A19的基本概念模型比較，會發現他們的本質上是相同的。

◎系統由一個或一個以上的Use Case組合而成
◎一個Use Case由一個或一個以上的Activity組合而成
◎每個Use Case有一個或一個以上的Actor
◎每個Use Case有可能影響外部系統（可能沒有）
◎每個Use Case都應該定義該Use Case的例外狀況（可能沒有）
◎每個例外狀況都要有一個或一個以上以上可能的其他Use Case
◎一個其他Use Case由一個或一個以上的Activity組合而成


在這裡主要的產出是Use Case的說明文件，也就是SRS，同時包含Activity Diagram與每個Activity的簡述。但是系統應該有一份Use Case List來核對系統限制的範圍，如果必要的話每個Actor（包含外部系統）也該有一份描述文件。另外，以Use Case為主的追溯資料也應該產生：像Use Case vs. Use Case、Use Case vs. Activity、Use Case vs. Actor等雙向的追溯表（在這裡應有五份）。

需要產生的文件雖然有很多份，幸運的是大多都只要在模型中建立再依據SoDA範本產生就可以應付。真的需要花心力輸入的主要還是SRS的資料。

B17 功能需求(4)──System Requirement Specification

無論在哪一個物件上，都會有靜態的描述與動態的行為存在，即使是Use Case也不例外；而SRS的內容大致上就由這兩類的資料所組成。

靜態的描述內容通常有：Use Case編號、名稱、描述、操作的Actor等，如果Use Case有特定的Nonfunctional Requirement需要達成也要註記在備註裡。（記得：NFR有哪些Use Case符合必須另外收集起來）與這個Use Case有關的客戶文件也必須裝訂在一起。

動態的行為內容通常有：進入流程前的系統狀態、啟動這個Use Case的條件、Use Case Scenario、Activity Diagram與Use Case結束時的系統狀態（如果有多個，都必須記錄如何操作會導致不同的結果）。在這個段落也應該註明自己被哪些Use Case所使用，同時又使用了哪些Use Case。

System Requirement Specification是需求分析後最重要的產出。之前所有收集的資料與分析的結果都會記錄在這裡，接下來無論是客戶確認、設計、實作、測試或製作文件，都會以這份資料作為延伸的標準。

功能需求是系統的組成單位，每個需求裡都描述清楚自己本身的特徵，同時記錄與其他功能需求之間的互動與關聯。良好分析之後的需求規格，會有比較高的機會導出擁有良好結構的系統。

◎系統的目標

B16 理論串接實作的瓶頸(3)──從Activity Diagram再refine Use Case

Activity Diagram只有流程圖的意義嗎？如果僅是這樣的話，那就不用浪費時間畫圖了吧。

在製作Activity Diagram的時候，除了Activity的順序與swim lane之外，我們還必須決定Activity的分類。原則上Activity屬於現在製作的Use Case，但是如果某個或某些特定順序的Activity已經出現在別的Use Case裡時，這表示這些Activity有reuse的現象發生。此時應該進行抽出共同部分的動作，意即把這些Activity另行放到一個新的Use Case裡，再讓現在的Use Case去參照拉出Use Case裡的Activity。

很多人都沒有發現這層意義，在表面上誤以為Activity Diagram只是表達流程概念，用漂亮的流程圖工具為每個Use Case畫了一張Activity Diagram後交差。由於UML定義的是表達想法的模型語言，大多數的人就只拘泥在表相的Language，而忘記Model才是它最深層的含意。

為每個Use Case表達流程概念、區分每個Activity所屬的swim lane、拉出共用的Activity為特定功能Use Case，經由表達、分析與提取，慢慢地找出隱含的關聯並為系統建立適當而完善的Use Case List，這是Activity Diagram在這裡的重要性。

一般人通常的想法是，因為系統要這個功能，所以這裡應該有什麼什麼才對；可是某甲認為該切成三個，某乙說應該有五個，這時要怎麼辦才好？如果沒法用科學化的方式分析出有幾個比較適當，那麼開發人員的想法會因為各自的主觀而難以同步。

B15 理論串接實作的瓶頸(2)──Activity Diagram的意義

Activity Diagram是用來說明Use Case內的動態流程，使用者操作步驟、系統當下該有的反應、與外部系統的互動都該在這份圖裡呈現。Activity的意義幾乎等於流程圖，但是如果把Activity Diagram畫得像流程圖，就極為可能造成系統界限與動作責任畫分不清楚的風險。

Activity Diagram裡有個叫swim lane的有用元件，我們可以使用它來基本地切分使用者動作、系統反應與外部系統的責任區塊。製作Activity時同樣像畫流程圖那樣依序加入，但加入時務必決定好該Activity在哪一塊區域內發生的。使用者作了什麼操作後進入系統處理，系統在內部如何處理、有什麼改變，改變之後如何與Actor互動，在這裡都依照發生的地方加以區隔開來。

這樣做有什麼好處呢？流程不是完全都一樣嗎？從整個操作順序與功能目的來看是沒什麼不同，但是從swim lane的權責角度來看就有很大的差異。使用者區塊代表的是人的動作，我們可以依區塊內的順序撰寫測試個案以及驗收時要交付的操作手冊；系統區塊代表的是需要開發的動作，在使用者的什麼動作後該有什麼樣的反應、做什麼樣的事是未來設計的依據；外部系統區塊代表的是系統與其他系統的互動，可以知道在什麼時間點要與外部系統有什麼樣的關聯，回傳的結果要如何處理等等。

把所有Activity放在所屬的swim lane對於系統開發的影響是非常大的，如果沒有注意到這個地方會使得動作無法明確區分而造成設計時的混亂。同樣地，在購買OOAD相關書籍時只要翻開Activity Diagram的範例，用有沒有swim lane的存在來得知作者有沒有過成功的實作經歷。

B14 Rational Tool(3)──Activity Diagram

Use Case Scenario應被畫成Activity Diagram。在製作的時候，要依使用者操作的順序，將屬於User的Activity依序往下排列。依照流程把Activity用箭號連接起來；每個需要系統反應的使用者操作，另在User Activity的右邊拉出一個屬於系統的Activity並串接起來。系統Activity結束時再接到下一個User Activit上直到結束。

所有的Activity都只用簡短的描述作為名稱，詳細說明輸入在註解欄裡。需要判斷的地方加上菱形並對流出的箭頭加上Guard Condition說明。直接畫Activity Diagram的話，其實與用Visio畫或者是用Word描述操作步驟有什麼不同，但是使用Rose的好處是我們在製作Activity Diagram的同時，可以作Activity的分類，將之歸納在它應屬於的Use Case裡，同時可以在任何時候從其他Use Case裡拉入該Activity。

Reuse Activity的好處在於我們對Activity的名稱有變動，或者再次分析發現必須移動所屬的Use Case時，可以直接動作並同時變更所有使用它的Activity Diagram而不必一一變動。用SoDA同樣可以自動在報表裡產生圖表與每一個Activity的說明文字。

在分類Activity與使用其它Use Case裡的Activity時，我們能夠更精確地判斷Use Case之間存在的關聯；同時在共用某些Activity次數多的時候，更易於決定要不要把那些Activity拉出成為獨立的Use Case。

B13 功能需求(3)──Use Case Scenario

記得嗎？工作項目是由一個以上的工作步驟組成的，Use Case也是由一個以上的操作步驟組成，這些有順序的操作步驟被稱Use Case Scenario。

Scenario是使用者達成該功能的操作順序，裡面記載了使用者與系統之間的互動與影響。Scenario必定會記錄所有可以正常完成的結果，有時也會另外記載一些錯誤時的系統反應。根據Scenario的說明我們可以得到使用者在該Use Case裡的操作順序，要保證系統正常的最低程度應該是依照Scenario裡的步驟去做都會有預期的結果；系統反應的方面可以作為設計與開發系統的依據，使用者操作順序可以用來驗證系統動作是否正常（意即測試），並且成為驗收時操作手冊的根本。

在訪談Use Case時就必須針對顯示的畫面、操作的動作、系統的反應與輸出的結果等細節加以確認，說明資料取得越詳盡越好，最好可以得到客戶的簽名確認。要客戶確認大部分的功能在專案的環境裡是比登天還難的，他們常常想到就會來改一下，所以應付這類突如其來的需求變更，系統必須要設計為易於開發且具有彈性才行。

在我看來Scenario還有個更重要的地方是在於，客戶會根據操作劇本的內容來驗收系統功能。正因為向上對應驗收條件，向下對應設計與測試，所以確認Use Case Scenario可以說是開發系統最值得注意的階段。

B12 追溯關係(1)──Use Case vs. Use Case

軟體專案裡要實作的功能是所有Use Case的集合，refine好所有的Use Case Diagram後首先要做的事是把所有的Use Case收集成清單；如果Use Case的數量太多時可以加上所屬Package的名稱輔助分群。Project vs. Use Case是第一份應該產生的追溯表（垂直），這簡單到不需要介紹它。

在Use Case Diagram裡，Use Case間有拉上關聯線條的就表示彼此有關係存在。這層關係的意義在於被使用的那一端有任何變動時，另一端的Use Case很可能會跟著變動，為了追溯某一個Use Case有變更的情形時，可以追查到受到影響的所有Use Case，在這個時間點應該產出Use Case的水平追溯表。

簡單來說，一個excel檔案的行與列依序填上所有的Use Case代號，從第一個Use Case開始找到最後一個，只要rose model裡的Use Case下有Association存在，就在交集的那個格子裡標註影響的方向（箭頭朝被使用的那個Use Case）。依序找出所有的Use Case間有關聯的格子並標明即可。

文件做一次都還好，麻煩的是哪天Use Case又重新調整過時要再重覆修改文件內容才是痛苦的事。幸好使用SoDA同樣可以自動產生這個追溯表（雖然不是表格形式）。SoDA可以設計一份文件，依編號順序列出所有的Use Case，同時在每一個Use Case裡定義搜尋所有的Association，記錄下影響到的Use Case與影響自己的Use Case。未來在修改某個Use Case時可以立即使用相互影響的範圍。

Model與View的相輔相成讓使用者只修改一次Model就產生各種想要的View，在此可以得到另一種實例的驗證。

B11 理論串接實作的瓶頸(1)──Refine Use Case Diagram的原則

剛接觸OOAD後，遇到的第一個小專案很興奮地使用UML來試著記錄需求。直接列出Actor與Use Case是很直覺的工作，除了摸索Rose的功能花了點時間之外，並沒有任何的困難。

作refine的動作時，Use Case不斷地被我思考並拆解為許多小型的Use Case，彼此間的關聯也拉了很多線條。同事看了問說關係看起來很複雜希望我說明一下？我就把我的想法說了一遍，包括如何拆解Use Case，如何用Use Case的關係表達心裡複雜的想法；原本十多個的Use Case就這麼被拆解成四五十個。

同事說需求模型並不是作設計，而是表達需求之間的關聯，。以我的切割方式已經幾近於切出元件的範圍，所以數量變得很多，同時關係彼此間串來串去而使得其他人很難看懂。Use Case的切割要以一個完整的功能為原則，在提取共用者時也得保持被提取的Use Case是一個完整而獨立的功能。

這個原則真的很難拿捏，太過時造成Use Case多而繁瑣，不及時也會形成每個Use Case各自為政，多想、多試、多討論應該是取得較佳平衡點的最好方式。如果在切割與不切割看起來都可以的時候，我傾向以不切割的結論，因為切得過多會增加需求模型的複雜度；而且每個Use Case都要附近詳細規格並列入清單時時檢查進度，這些都會是多投入資源的工作。

好的開始是成功的一半；如果製作了一個很難分析與設計的需求模型，那真的會是個悲慘的開始。

B10 Rational Tool(2)──Refined Use Case Diagram

在refine use case diagram時，我會優先處理Actor的整理，因為可以減少Actor對Use Case的使用關係。實作時有交集Use Case的Actor另外拉出一個Actor直接關聯，並消除原先Actor與那些Use Case的關聯。

接著就找出Use Case裡隱含的其他Use Case；例如以“管理”為名稱的Use Case就很可能具有CRUD（Create，Retrive，Update，Delete）四個Use Case。找出所有可以延展開的Use Case並與原本的Actor拉上關聯。

再來是最難做好的部分，我要要去檢視所有的Use Case，研究Use Case的劇本來判斷是否有些步驟適合另外定義出新的Use Case，同時會這些新的Use Case定義與原來Use Case的關聯。如果運作正常的劇本必定會使用這個Use Case，就在stereotype標註include；如果某些特定狀況才會使用這個Use Case就標註extend。

當所有的Actor與Use Case通過review後，就為所有的Use Case標上標號。這時，開發系統所必須完成的功能，就已經包含在所有的Use Case裡頭。

B09 功能需求(2)──Refine Actor & Use Case

完全對應客戶訪談的結果所列出的Actor與Use Case是一種原始的資料，如果直接依這個結果開發系統，每一個Use Case都各做各的事而完全沒有交集。就像每一個人都各自只從頭到尾處理自己的訂單一樣，許多Use Case裡都做了可以抽取出來的相同事項，每一次該事項出現都重覆投入資源去處理。所以在決定原始的Use Case Diagram之後我們緊接著要先做抽取相同部分的工作。

Actor間可以定義的關聯是繼承，繼承可以簡化許多原本複雜的關聯。當Actor1的全部Use Case是Actor2的一部分時，可將Actor1定義為繼承Actor2；當Actor3與Actor4的Use Case有大量的交集時，可以將交集的Use Case定義給一個新的Actor5，而Actor3與Actor4都繼承了Actor5。

Use Case可以定義的關係通常是繼承、include與extend。當Use Case1的定義是Use Case2內容的一部分時，Use Case2繼承Use Case1；當Use Case 3的主要流程一定會執行Use Case4的功能時，Use Case3 include Use Case4；當Use Case5根據某個特殊狀況的成立才需要執行Use Case6時，Use Case6 extend Use Case 5。

Refine需求模型只有原則而沒有標準，但是Actor與Use Case定義的好不好，卻對專案的設計有很大的影響。每個物件定義得越明確對未來會越有利，而且在定義後應讓專案人員review，一方面可以確認自己的定義是否合理，另一方面也讓其他人員明白自己對於系統的想法。

B08 做事的方法(4)──相同的抽取出來，差異的分派下去

現在的社會強調分工，很少再有從頭到尾一人包辦所有事情的情況。例如一張訂單會由業務去接洽合約內容、工程人員去著手設計系統、採購去購買合乎規格的設備、會計會確認所有應付與應收的帳款；以此原則，無論有幾張訂單進來，每個部門所負責的事項都不會改變。從單張訂單的觀點來看，這是分工；改從很多張訂單的觀點來看，同樣的事情集中到同樣的部門處理，這就是抽取。

一張訂單被切割為幾個必要的部分，每個部分都集中給固定的群組處理。業務處理的是接洽合約、工程人員主管設計、採購與會計也各有各的事情要做；所有合約的相同部分抽出給特定人員處理，所有的部分只處理合約特定部分的事項。如果遇到合約出現問題時，再依問題的項目分派給應負責的部門，依該部門的專長來處理特別的情況。

不過以上面的狀況來說，訂單的處理會經歷不同的部門，每個部門都只做好自己的部份再將之依流程給下一個部門。因此會指定一個負責人員來控管訂單這個物件，隨時判斷它目前在什麼階段，是否出現什麼差錯而需要額外指派什麼工作好讓它回到正常流程。這樣的角色在專案控制工作項目的進行者稱為PM(Project Manager)，在系統設計裡專門控制功能執行的程式稱為controller。

雖然控管者與執行者可以是同一個人，但是由同一個人兼任容易造成角色混淆，還有工作交接較複雜的情形。工作因抽取而變為數個不同階段的同時，建議指派一個人負責控管該工作項目的進行狀況。

B07 Rational Tool(1)──Use Case Diagram

不管是Actor還是Use Case，在數量多的時候一定要依特性分開到不同Package存放；當特性明顯到屬於獨立的功能區塊時，Package可使用名為subsystem的stereotype作為識別。需求階段的UML在Rose裡應放置在Use Case View裡頭。

建立需求模型（Requirement Model）時大致上要做的事項是：
◎建立所有需要的Package（含subsystem）。
◎建立所有的Actor並放置在所屬的Package裡，同時一一命名。
◎建立所有的Use Case並放置在所屬的Package裡，同時一一命名。（還不用給UC序號）
◎依序在每個Package建立所需要的Use Case Diagram並予以命名。

接著，對於每張Use Case Diagram，要做到以下事項：
○拉進所有需要的Actor，放置在圖的左邊。
○根據Actor的需要，拉進所有有關聯的Use Case並建立關係；Use Case要放置在圖的中間。
○根據Use Case的需要，拉進所有被該Use Case影響的Actor（外部系統）放置在圖的右邊。

因為沒打算做成Rational Tool的教學，所以這裡只會提到一些思考或實作原則。下面是一個Use Case Diagram的簡單範例。

B06 功能需求(1)──Actor & Use Case

系統的存在是要給人或其它系統操作用的，使用系統的對象稱為Actor。訪談的第一優先是找出未來操作系統的所有Actor。系統應該會有管理者，同時一定會有使用者，使用者依定義的不同可能分為許多類型，我們必須確認出所有Actor的類型並記錄。

接著就開始陸續訪談所有類型的數個Actor，收集他們心裡希望系統提供的功能。訪談Actor有兩個主要目的：一方面要得知每種類型Actor所想要執行的功能清單，另一方面是詢問出每個功能的詳細資料以定出規格。（當然，藉由訪談來拉近客戶的關係同時充實自己對客戶工作領域的知識也是重要的課題）

訪談完後我們應該可以得到每種Actor所要執行的功能清單與每個功能的詳細資料（內容與用途在B13）。在文件記錄的時候一個功能會等同定義為一個Use Case。一開始我們必須建立所有的Actor並寫入其描述，接著建立每個Actor要使用的所有Use Case並拉上關聯，做完的同時我們可以收集所有的Use Case得到系統的完整功能清單。

有的Use Case會被定義為與外部系統有關聯，這個時候被影響的外部系統也被視為一種Actor。它們之間的關係也是應該被記錄下來。

如果有沒有Use Case的Actor或是沒有Actor的Use Case，與客戶確認真的沒有任何使用關係後將之刪除。定義沒事做的使用者與做出沒有人用得到的功能都會浪費資源，必須記得系統是以滿足使用者需求為優先的。

B05 Review的重要

心裡的想法如果不記下來，會有遺忘的風險；但是記下來的想法，保證是對的嗎？同時也保證其他人知道你的想法嗎？

維護沒有設計文件與註解的系統時，曾經遇到幾個看來不難的問題，那時依自己的判斷加以修改，測試後也都沒有問題。但是過了一段時間，以前參與設計的人看到就說，那些問題不應該修改在那裡而是在別的地方。設計的想法沒有同步就會有作法不一致的問題產生。

在我帶幾個人開發系統時，工作分派下去之後每天上下午各抽出半個小時討論，內容是簡單說明自己如何做出功能的想法。說明的同時，所有人會針對不明白的地方提問並要求再解釋；如果作法不順暢的時候，也經由問答間找出更好的想法與作法。經由這個方式，所有成員都清楚知道別人想做的事項與要使用的方法，往後工作產生問題時所有人都可以快速地互相支援。在固定定期review的期間主管還抱怨我們怎麼開會這麼頻繁呢。

review的確需要所有人額外花時間投入，但是可以得到想法正確性的驗證、所有成員瞭解全部工作事項、確認記錄文件的正確性與完整性。在規畫與設計時及早發現問題予以修正，會比實際做到一半才發現不對勁要去修改來得快速且影響較小。如果你曾遇過開發到中途才發現嚴重的問題，必須修改大半原來想法之類的經驗，那麼你應該會接受多花一些review的時間來減低未來的錯誤發生機率。

revieｗ的內容，以需求階段、架構設計、細部設計的文字文件與UML文件為主，最好是全部的設計文件都進行。