2012年2月24日

6.4-備妥StarUML及敘述格式


寫給SA的UML/MDA實務手冊
----------
第6章-分析系統流程



6.4-備妥StarUML及敘述格式

PIM-1的主要產出是系統UC敘述,採用MS Word。不過,雖說如此,我們還是要求系統分析師在StarUML中,針對每組的系統UC都建立一張專屬的系統UC圖,便於觀看與管理。操作步驟如下:

1.          在「PIM-1:分析系統流程」底下,新增一張系統UC(Add Use Case Diagram),並更名為「第1組系統UC圖」,如圖6-7所示。

6-7:  新增UC

2.          隨後,開啟第1組系統UC圖,並點開「CIM-3:定義系統範圍」底下的「投資人」套件,點選套件下的「投資人」參與者,並且拖曳至UC圖面空白處。此時,在UC圖面處,就出現一個投資人圖示了,如圖6-8所示。
6-8:  拖曳加入參與者

3.          依照上述拖曳步驟,依序拖曳「投資人」套件底下的「網路申購單筆基金」、「網路申購定期定額基金、「定期定額約定異動」和「綜存系統」至UC圖面,如圖6-9所示。

6-9:  拖曳加入其餘的UC及參與者

4.          依照上述步驟,從不同的套件底下拖曳出第1組的系統UC,最後匯出如圖6-6的第1組系統UCJPG圖檔。

(請參照前圖6-6)
6-6  1組系統UC

此外,我們設計了一份開放式的UC敘述格式如下表。針對每一個UC,所獲取的細節內容有所不同,所以系統分析師並不需要使用所有欄位。系統分析師可以將此表放置於每份UC敘述文件的首頁,勾取有所紀錄的欄位,讓觀看者一眼就可以知道UC敘述內容涵蓋哪些資料。

UC名稱  UC編號  UC簡述  UC  □系統  □參與者 
□相關UC  □其他(                                         )
□主要流程  □替代流程  □例外流程
□其他(                                                    )
□啟動事件或要件  □執行前要件  □成功時要件  □失敗時狀態
□企業規則  □其他(                                        )
UC敘述的歷史版本  UML  □參考畫面  □非UML文檔
□其他(                                                    )
□優先性  □循環等級  □待解議題  □基本假設  □相關人員
□特殊需求  □其他(                                        )
□其他(                                                    )



2012年2月23日

6.3-備妥CIM-3:系統UC圖


寫給SA的UML/MDA實務手冊
----------
第6章-分析系統流程



6.3-備妥CIM-3:系統UC

在進入PIM-1訪談前,系統分析師必需先備妥第1組系統UC名單,如圖6-6所示:

1組系統UC名稱
簡述
SUC001-網路申購單筆基金
投資人上網下單購買某檔基金。
SUC002-網路申購定期定額基金
投資人上網申購定期定額基金。
SUC003-定期定額約定異動
投資人上網更改定期定額約定。
SUC004-代客申購單筆基金
投資人臨櫃申購基金,理專使用系統代客申購單筆基金。
SUC005-代客申購定期定額基金
投資人臨櫃申購定期定額基金,理專使用系統代客申購定期定額基金。
SUC006-扣款申購當期基金
系統於約定日自動扣款申購一筆基金。

6-6:  1組系統UC

2012年2月22日

6.2.5-其他事項


給SA的UML/MDA實務手冊
----------
第6章-分析系統流程
6.2-PIM-1:分析系統流程


6.2.5-其他事項
  • 優先性:替UC標示其重要度或優先性,可以協助訂定開發UC的順序,愈重要的愈優先開發。
  • 循環等級:替UC標示其細緻度或循環等級,方便開發人員經過多次循環的過程逐步定義出UC的細節。例如,可以簡單地將UC敘述分成兩個循環:先做要點敘述,後做寫實敘述。要點敘述通常僅會紀錄參與者或系統的需求(What)。當開發專案持續進行,開發人員對UC會有更多的了解,便可以進一步記載參與者或系統的執行細節(How to),細述參與者與系統兩方對話流程(Dialog Process)
  • 待解議題:在UC分析與開發期間,可能會出現還沒有定論的問題,這時候透過UC敘述把問題紀錄起來,方便指派負責人員以及日後查閱。
  • 基本假設:如果該UC是基於某個基本假設而設計出來的,記下這個重要的基本假設。在基金模擬個案中,估算基金帳戶內的現值時,通常以基金公司提供的基金淨值為估算(基本假設),但投資人贖回基金時還是得以基金公司公告的實際報價為主。
  • 相關人員:每一份UC敘述都涉及幾種不的身分的相關人員,包括製作者、觀看者和審核者等等。在UC導向(UC Driven)的系統開發實務上,常常將一個UC當成一個工作單元,加上相關人員的簽核之後,UC敘述文件就成了現成的工作單(Work Ticket),也可透過工作流程工具(Workflow Tool)來管理。
  • 特殊需求:跟該UC相關的非功能性需求等等的特殊需求,都可以記錄在這個欄位中。



2012年2月21日

6.2.4-相關文檔


給SA的UML/MDA實務手冊
----------
第6章-分析系統流程
6.2-PIM-1:分析系統流程



6.2.4-相關文檔

由於UC導向(Use Case Driven)是當今軟體開發的基礎模式,所以UC敘述常做為系統開發文檔的匯集點,由它連結到攸關的文檔。一旦,企業流程或需求有所變動時,可以快速搜尋出以UC敘述為首的一連串相關文檔,然後進行修改,如圖6-5所示。


6-5:  UC敘述組織相關文檔

常見的相關文檔有:

  • UC敘述的歷史版本:UC改版時,UC敘述也跟著同步改版。UC敘述是參與人員的智慧成果,也是企業的重要資產。所以,如果有需要保留UC敘述的歷史版本時,可以在現行版本裡多加一個欄位連結舊有的歷史版本,以及改版說明。
  •  UML圖:跟該UC相關的企業UC圖、活動圖、系統UC圖、狀態圖、類別圖或循序圖等等。
  • 參考畫面:有時候附上畫面設計的圖片,讓觀看者可以對該UC有更具體的想像。只要該UC的參與者是人類使用者的話,就可以配合參考畫面,以說明UC的執行過程。口說無憑,有圖片為證,比較能夠令人信服和理解。不過,UC敘述裡只是附上參考畫面,不受限系統畫面最後要一模一樣。所以說這只是參考畫面,其目的只是要讓觀看者更容易理解及想像系統未來提供服務時的樣貌。
  • 其他非UML文檔:例如會議紀錄、XSD文檔、表格設計等等。



2012年2月17日

6.2.3-要件及規則


給SA的UML/MDA實務手冊
----------
第6章-分析系統流程
6.2-PIM-1:分析系統流程



6.2.3-要件及規則
  •  啟動事件或條件:記錄啟動UC的重要事件或條件。
  •  執行前要件:這是執行UC之前的檢驗,惟有在滿足某些重要條件時,才會執行該UC,以確保UC可以正確執行。
  • 成功時要件:相對於執行前要件,成功時要件代表UC執行完畢時,可以透過成功時要件自行檢驗是否執行成功。
  • 失敗時狀態:記錄UC執行失敗時的狀態。
  • 企業規則:重要的企業規則或計算公式都要記錄下來。


企業員工在執行企業流程時,會使用到許多重要的企業規則或計算公式,這些也都是系統必須遵守的要件及規則,所以必須記錄下來。比方說,在基金模擬個案中,就有如下的要件及公式:
  • 定期定額申購最低金額,國內基金為三千元,境外基金為五千元。(企業規則)
  • 單筆申購最低金額,國內基金為一萬元,境外基金為三萬元。(企業規則)
  • 申購金額以千元為倍數。(企業規則)
  • 定期定額申購扣款日為每月51525日擇一扣款。(企業規則)
  • 定期定額當月未扣款成功,將不再補款。(企業規則)
  • 債券型基金只承作單筆申購。(企業規則)
  • 手續費=申購金額×基金管理費×銀行折扣。(計算公式)


2012年2月16日

6.2.2-執行流程


給SA的UML/MDA實務手冊
----------
第6章-分析系統流程
6.2-PIM-1:分析系統流程



6.2.2-執行流程
  •  主要流程:這是UC敘述最核心的部份,其記載了整個UC正常的執行過程。
  • 替代流程:一個UC敘述裡面,通常會包含一段主要流程,同時可以包含數段替代流程。如果將主要流程比擬成經常使用的大馬路的話,替代流程就是比較少用的羊腸小徑,不過走完一段羊腸小徑之後,小徑的盡頭還是會再度接回大馬路。
  • 例外流程:例外流程跟替代流程不同,替代流程這條小徑的盡頭會接回主要流程,可是一旦進入了例外流程之後,系統將不會繼續執行完剩下的主要流程。也就是說,例外流程這條小徑的盡頭不會接回主要流程。


在基金模擬個案中,投資人上網申購單筆基金的正常流程就是主要流程。可是,有些投資人在申購的過程中可能不是這麼順暢。例如,單筆申購國內基金最低金額是一萬元,如果投資人沒有注意到這個限制,鍵入低於一萬元的申購金額的話,這時可以用替代流程來說明該如何處理這種狀況。

替代流程跟例外流程有細微差異。UC成功執行的過程中,正常流程就是主要流程,期間出現的小插曲就是替代流程。但是,例外流程處理的是,UC執行失敗的情況。例如,網路有問題,導致申購交易時間逾時,這時候「上網單筆申購基金」的系統UC就算執行失敗,所以會引發例外流程,來處理UC執行失敗的事件。

如果配上編號條列敘述流程的話,更加便於管理、記錄、討論及增修敘述內容。一般而言,每條敘述前面的編號通常並不嚴格用來表示依序,更重要的是,可以用來提供指稱的標號。如此一來,就可以方便迅速指出某一段流程內容。

慣用的編號方式是,主要流程裡的步驟以1234的數字編列,次步驟編為1.11.21.31.4。而替代流程則參照主要流程的編號,加上abcd的字母編列。例如,執行第3號主要流程可能發生的第1條替代流程就編為3.a,第2條替代流程編為3.b。至於,替代流程的次步驟則編為3.a.13.a.23.a.33.a.4。如果,替代流程隨時可能發生,而不依附特定的步驟時,則以星號取代主要流程的數字,編為*.a*.b*.c*.d,其次步驟編為*.a.1*.a.2*.a.3*.a.4。

請看圖6-4的例子,其主要流程共有6個步驟或項次,其中3號步驟底下又細分成3個次步驟,編號為3.13.23.3。至於,5號步驟底下也細分成2個次步驟,編號為5.15.2。主要流程中的2號步驟,可能發生4個替代流程,編為2.a2.b2.c2.d。其中的2.b號替代流程底下又可細分成3個次步驟,所以依序編號為2.b.12.b.22.b.3。而主要流程中的5.2號步驟,也可能發生4個替代程序,編為5.2.a5.2.b5.2.c5.2.d。其中的5.2.b號替代流程底下又可細分成3個次步驟,所以依序編號為5.2.b.15.2.b.25.2.b.3

同時,還有4條隨時可能發生的替代流程,並不依附在任何一條主要流程底下。因此,為它們編號為*.a*.b*.c*.d。其中的*.b號替代流程底下又可細分成3個次步驟,所以依序編號為*.b.1*.b.2*.b.3

6-4:  流程編號擴充關係

2012年2月15日

6.2.1-UC基本資料


寫給SA的UML/MDA實務手冊
----------
第6章-分析系統流程
6.2-PIM-1:分析系統流程



6.2.1-UC基本資料
  • UC名稱:一個UC擁有一份UC敘述,所以UC敘述文件裡面,一定要標示出對應的UC名稱。
  • UC編號:UC敘述是UC的一部分,所以UC敘述沒有自己的編號,而是拿UC的編號當作UC敘述的編號。
  • UC簡述:只需三言兩語,簡潔說明該UC,以增強UC敘述的可理解性。
  • UC圖:在UC敘述的開頭處附上相關的UC圖件,不僅可以一目暸然地得知UC的名稱、參與者名稱等,也豐富了UC敘述的表達方式,擺脫文字格式的單調性。
  • 系統:就是提供此UC的系統名稱。有時候在所附上的UC圖件裡可能出現負責提供此UC的系統名稱。
  • 參與者:參與者可能具備不同特質,所以有時會將其細分,例如細分成「啟動者」及「支援者」。
  • 相關UC:常見的相關性有兩方面,其一是執行UC前必須先行執行過某相關UC,其二是執行UC期間可能驅動其他的包含UC(Inclusion Use Case),或是因條件符合驅動其他的擴充UC(Extension Use Case)

就系統內觀而言,各UC在其幕後都是共用同一群物件。也就是說,UC之間自然就具有「共用物件」之關係。但是,由於UC圖只呈現系統外觀,所以在UC圖裡看不到這種關係。在外觀方面,UC之間有兩種關係,分別是「包含」(Include)和「擴充」(Extend)關係。

兩個UC之間可以有「包含」關係,用以表示某一個UC的對話流程中,包含著另一個UC的對話流程。一旦出現數個UC都有部份相同的對話流程時,將相同的流程記錄在另一個UC中;前者稱為「基礎UC(Base UC),後者稱為「包含UC(Inclusion UC)

如此一來,這些基礎UC就可以共享包含UC,而且未來其他的UC只要建立了包含關係,就可以立即享用已經在其他UC定義好的相同對話流程了。在基金模擬個案中,投資人只要上網申購單筆基金,就會收到一封交易成功的通知電郵,如圖6-1所示。

6-1:  包含關係

由於,投資人上網申購定期定額基金,也會包含一段電郵交易通知對話流程,此時可以使用包含關係,重用已經寫好的「電郵交易通知」系統UC,如圖6-2所示。此時,針對「網路申購定期定額基金」系統UC敘述,系統分析師就不需要再重寫一次「電郵交易通知」的敘述了。

6-2:  重用包含UC

簡言之,包含關係是來自於抽象的動作(Abstraction),即從數個不同的UC 之中,抽離出共同的部分,而成為可以重用的UC。系統分析師必需為每個UC撰寫UC敘述,一旦將共同的敘述抽象出來,就不必在「網路申購單筆基金」和「網路申購定期定額基金」的UC敘述中重複描述出「電郵交易通知」了。

這一來,就大大簡化了「網路申購單筆基金」和「網路申購定期定額基金」的UC敘述內容了。此外,當系統分析師有必要去修改「電郵交易通知」的UC敘述時,也不必更動到「網路申購單筆基金」和「網路申購定期定額基金」的UC敘述內容了。

兩個UC之間可以有「擴充」關係,用以表示某一個UC的對話流程,可能會依條件臨時插入另一個UC的對話流程中;前者稱為「擴充UC(Extension UC),後者稱為「基礎(Base UC)

有了擴充關係後,便可以將特定條件下才會引發的流程記錄於擴充UC中。當執行基礎UC期間,可以只是單純地執行基礎UC所記載的流程;但是在特定條件發生時,則會額外插入並執行擴充UC所記載的流程。在基金模擬個案中,理專代客申購單筆基金之後,可以依投資人要求列印申購收執聯,如圖6-3所示。

6-3:  擴充關係

簡言之,擴充關係來自於UC內執行活動的過程有分為主要過程(Main Course)及可選擇性過程(Alternative Course)。在基金模擬個案中,有些投資人可能跟理專認識多年,所以在臨櫃申購基金時,也不需要理專列印申購收執聯給他。有些投資人較為謹慎,所以會要求理專列印申購收執聯。申購基金的過程是主要過程,而列印申購收執聯則為可選擇性過程。


2012年2月14日

6.2-PIM-1:分析系統流程


寫給SA的UML/MDA實務手冊
----------
第6章-分析系統流程


6.2-PIM-1:分析系統流程



針對每一個系統UC,系統分析師分析其內部細節,並編寫成系統UC敘述(UC Description)。UML並未提出標準的敘述格式可供遵守,不過系統分析師可以在網路上找到許多實用的UC敘述格式,或者翻閱一些UML或UC相關書籍,也可以發現許多很有特色的UC敘述格式。

本書也會提供一個UC敘述格式,供系統分析師參考。不過,我們的建議是,挑一個UC敘述格式開始使用之後,逐步加入自己的需求,最後客製化成更適用的UC敘述格式。或者,系統分析師已經有一個中意的UC敘述格式了,那不妨耐心往下閱讀本書所提供的UC敘述格式,從中篩選出可用的元素,加到自己的UC敘述格式中。

一份UC敘述格式裡頭包含多項欄位,如下條列出實務上常見的欄位,並將之細分為5大類方便於次小節詳述之。系統分析師可以從中挑選適用的欄位組成自己的UC敘述格式。

1. UC基本資料

  • UC名稱
  • UC編號(ID)
  • UC簡述
  • UC圖
  • 系統
  • 參與者
  • 相關UC

2. 執行流程

  • 主要流程(Basic Flow)
  • 替代流程(Alternate Flows)
  • 例外流程(Exception Flows)

3. 要件及規則

  • 啟動事件或條件(Triggers)
  • 執行前要件(Preconditions)
  • 成功時要件(Postconditions on Success)
  • 失敗時狀態(Status on Failure)
  • 企業規則(Business Rule)

4. 相關文檔

  • UC敘述的歷史版本
  • UML圖
  • 參考畫面
  • 其他非UML文檔

5. 其他事項

  • 優先性(Priority)
  • 循環等級(Iteration)
  • 待解議題(Issues)
  • 基本假設(Assumptions)
  • 相關人員
  • 特殊需求(Special Requirements)



2012年2月13日

6.1-模擬CIM-3:定義系統範圍



寫給SA的UML/MDA實務手冊
----------
第6章-分析系統流程


6.1-正式進入分析階段

在CIM階段,系統分析師約莫花一~二週的時間,盡快產出初步的系統UC,以便讓相關的決策人員可以從中挑選出首期開發的系統UC,而這也就是首期的系統範圍。

隨後,專案正式進入PIM階段,也是正式進入分析階段,所以系統分析師將投入更多的時間,針對首期的系統UC詳述細部規格,做為正式需求文件的一部份,也做為企業人員與開發人員之間的溝通文件。

本書預設PIM-1~4的UML產出,做為需求文件中的一部份,其餘非UML產出,系統分析師視專案規定或過往經驗自行產出,本書不涵蓋非UML產出。在PIM階段中,系統分析師負責產出PIM-1~4,至於其餘的PIM或PSM則由其他開發人員負責產出。PIM-1~4的產出如下:

PIM-1:分析系統流程(系統UC敘述)
PIM-2:分析企業規則(狀態圖)
PIM-3:定義靜態結構(類別圖)
PIM-4:定義操作及方法(循序圖)

此外,系統分析師需多加注意,CIM階段與PIM階段的產出方式略有不同。系統分析師在結束CIM階段之後,才決定出PIM階段的系統範圍,也同時正式進入PIM階段。但是,在進入到PIM階段之後,系統分析師將所有系統UC依相關性分成數組,以組別方式產出該組系統UC涉及的PIM-1~4產出,隨後交給後續的開發人員進行設計、編碼及測試。然後,逐步產出一組一組的PIM-1~4產出,跟CIM的產出方式不同。

最後,我們以基金模擬個案的產出時程,解釋系統分析師逐步產出PIM的可能情況:

第一週:系統分析師進行CIM-1產出6個企業UC。

第二週:系統分析師進行CIM-2產出20張活動圖。

第三週:系統分析師進行CIM-3產出80個系統UC。

第四週:決策人員從CIM-3挑選出40個系統UC,做為首期系統範圍。同時,系統分析師將40個系統UC,以其領域知識的相關性分成8組。如下,我們只列出第1組系統UC名單,省略第2~8組的系統UC名單。




第五~六週:產出第1期系統UC相關的PIM-1~4分析文件,並交由後續的開發人員進行設計、編碼及測試。

第七週之後:依序產出第2~8期系統UC相關的PIM-1~4分析文件,並交由後續的開發人員進行設計、編碼及測試。