書籍::《寫給SA的UML/MDA實務手冊》pdf

《寫給SA的UML/MDA實務手冊》一書已經絕版，我把原稿轉成pdf檔，販售$99元，有興趣購買者請於轉帳後發信給我(271080@gmail.com)，我會依照來件信箱轉寄pdf檔。來信請告知您的轉帳帳號末5碼，我的帳號如下：

永豐銀行(807)；帳號(010-004-0008097-8)

$99元電子書目錄：

1.《寫給SA的UML/MDA實務手冊》，售$99元。

2.《UML答客問》二合輯(2個pdf檔)，售$99元。

3.《學會UML/OOAD這樣開始就對了》，售$99元。

4.《寫給C++程式設計師的UML實務手冊》，售$99元。

5.《OCUP/UML初級認證攻略》，售$99元。

6.《IT人，你如何表達？》，售$99元。

7.《寫給SA的UML/UseCase實務手冊》，售$99元。

---------

目錄

第1章-Why系統分析師需要學習UML
第2章-做好系統分析先睹為快
第3章-定義企業流程
第4章-分析企業流程
第5章-定義系統範圍
第6章-分析系統流程
第7章-分析企業規則
第8章-定義靜態結構
第9章-定義操作及方法
第10章-基金模擬個案
第11章-語音備忘器

----------
第1章-Why系統分析師需要學習UML
1.1-Why系統分析師需要學習UML
1.2-UML並非萬能
1.3-UML圖
1.4-重要的OO及UML概念
1.4.1-物件
1.4.2-屬性與操作
1.4.3-操作與方法
1.4.4-封裝
1.4.5-類別
1.4.6-一般化關係
1.4.7-結合關係
1.4.8-聚合關係
1.4.9-組合關係
1.4.10-使用案例與參與者
1.4.11-企業UC與系統UC
1.5-MDA開發程序
1.5.1-MDA的主張
1.5.2-MDA的開發程序
1.5.3-MDA在晶片設計的應用
1.5.4-本書所採用的分析步驟
1.6-UML對MDA的助益
1.6.1-中立機構負責維護UML
1.6.2-中立的模式語言
1.6.3-Profile支持客製化UML方言

第2章-做好系統分析先睹為快
2.1-CIM-1：定義企業流程
2.2-CIM-2：分析企業流程
2.3-CIM-3：定義系統範圍
2.4-PIM-1：分析系統流程
2.5-PIM-2：分析企業規則
2.6-PIM-3：定義靜態結構
2.7-PIM-4：定義操作及方法
2.8-在CIM與PIM之後

第3章-定義企業流程
3.1-Why需要定義企業流程
3.2-CIM-1：定義企業流程
3.3-備妥StarUML
3.4-模擬CIM-1：定義企業流程

第4章-分析企業流程
4.1-CIM-2：分析企業流程
4.2-備妥CIM-1：企業UC模式
4.3-備妥StarUML
4.4-模擬CIM-2：分析企業流程

第5章-定義系統範圍
5.1-CIM-3：定義系統範圍
5.2-備妥CIM-2：活動圖
5.3-備妥StarUML
5.4-模擬CIM-3：定義系統範圍

第6章-分析系統流程
6.1-正式進入分析階段
6.2-PIM-1：系統UC敘述
6.2.1-UC基本資料
6.2.2-執行流程
6.2.3-要件及規則
6.2.4-相關文檔
6.2.5-其它事項
6.3-備妥CIM-3：系統UC圖
6.4-備妥StarUML及敘述格式
6.5-模擬PIM-1：分析系統流程

第7章-分析企業規則
7.1-Why分析企業規則
7.1.1-刺激／反應規則
7.1.2-操作規則
7.1.3-結構規則
7.1.4-推論規則
7.1.5-計算規則
7.2-PIM-2：分析企業規則
7.3-備妥StarUML
7.4-模擬PIM-2：分析企業規則
7.5-使用StarUML繪製狀態圖

第8章-定義靜態結構
8.1-PIM-3：定義靜態結構
8.2-善用交易樣式
8.3-備妥PIM-2：狀態圖
8.4-備妥StarUML
8.5-模擬PIM-3：定義靜態結構

第9章-定義操作及方法
9.1-PIM-4：定義操作及方法
9.2-幾項建議
9.3-備妥StarUML
9.4-模擬PIM-4：定義操作及方法
9.5-使用StarUML繪製循序圖

第10章-基金模擬個案
10.1-CIM-1：定義企業流程
10.2-CIM-2：分析企業流程
10.3-CIM-3：定義系統範圍
10.4-PIM-1：分析系統流程
10.5-PIM-2：分析企業規則
10.6-PIM-3：定義靜態結構
10.7-PIM-4：定義操作及方法

第11章-語音備忘器
11.1-專案緣起
11.2-CIM-3：定義系統範圍
11.3-PIM-1：分析系統流程
11.4-PIM-2：分析企業規則
11.5-PIM-3：定義靜態結構

7.5-使用StarUML繪製狀態圖

給SA的UML/MDA實務手冊
----------
第7章-分析企業規則

7.5  使用StarUML繪製狀態圖

接下來，系統分析師可以按照下列步驟，使用StarUML繪製狀態圖。

1.          點選工具箱裡的實心小圓InitialState(起點)圖示，如圖7-19所示。

圖7-19:  點選InitialState

2.          隨後，在圖面空白處再點一次，新增了一個起點，如圖7-20所示。

圖7-20:  新增起點

3.          點選工具箱裡的圓角矩形State(狀態)圖示，如圖7-21所示。

圖7-21:  點選State

4.          隨後，在圖面空白處再點一次，並為新增的狀態更名為「初始設定」，如圖7-22所示。

圖7-22:  新增狀態

5.          雙擊「初始設定」狀態之後，在狀態圖示右邊出現新增動作的小選單，依序為EntryAction(進入行動)、DoAction(Do行動)和ExitAction(離開行動)，如圖7-23所示。

圖7-23:  雙擊狀態

6.          點選DoAction，並為新增的行動更名為「設定交易資料」，如圖7-24所示。

 圖7-24:  新增動作

7.          雙擊「設定交易資料」行動之後，在狀態圖示右邊出現關於Do行動的選單，按下加號新增「計算交易金額」和「產生交易編號」行動，如圖7-25所示。

圖7-25:  新增動作

8.          點選工具箱裡的帶箭頭實線Transition(轉換線)圖示，如圖7-26所示。

圖7-26:  點選Transition

9.          隨後，點選「起點」並拖曳至「初始設定」放開，建立出兩者之間的轉換線，如圖7-27所示。

圖7-27:  新增轉換線

10.      依照上述步驟新增「正常扣款」和「自動申購」狀態，以及兩者之間的轉換線，同時開啟轉換線的性質表，如圖7-28所示。

圖7-28:  性質表

11.      點選性質表裡的Triggers(驅動)項次，並於開啟的頁籤中新增一個名為「約定日到」的事件，如圖7-29所示。

圖7-29:  新增事件

12.      隨後，StarUML標示出「約定日到」事件於轉換線旁，如圖7-30所示。

圖7-30:  約定日到

13.      點選工具箱裡的空心小圓ChoicePoint(選擇)圖示，如圖7-31所示。UML改版之後，將此圖示改成空心小菱形，並更名為「選擇狀態」(Choice Pseudostate)。

圖7-31:  點選ChoicePoint

14.      隨後，在圖面空白處再點一次，並新增「自動申購」和「選擇」兩者之間的轉換線，以及「扣款失敗」事件，如圖7-32所示。

圖7-32:  新增選擇

15.      新增「終止扣款」狀態，並建立與「選擇」兩者之間的轉換線。同時，開啟轉換線的性質表，於性質表裡的GuardCondition(警戒條件)空格，填入「扣款期數=1」，如圖7-33所示。

圖7-33:  新增警戒條件

16.      隨後，StarUML標示出「扣款期數=1」警戒條件於轉換線旁，如圖7-34所示。

圖7-34:  警戒條件

17.      點選工具箱裡的雙圓FinalState(終點)圖示，如圖7-35所示。

圖7-35:  點選FinalState

18.      隨後，在圖面空白處再點一次，新增了一個「終點」，並建立與「終止扣款」兩者之間的轉換線，如圖7-36所示。

圖7-36:  新增終點

19.      新增另一個選擇，並且建立起兩個「選擇」之間的轉換線。隨後，開啟兩「選擇」之間轉換線的性質表，新增「扣款期數>1」的警戒條件，以及新增「扣款失敗」的事件。

20.      接著，點選性質表裡的Effects項次，並於開啟的頁籤中新增一個名為「累計失敗次數」的轉換行動，如圖7-37所示。

圖7-37:  新增一個轉換行動

21.      隨後，StarUML標示出「扣款失敗[扣款期數>1]/累計失敗次數」的字眼於轉換線旁，如圖7-38所示。

圖7-38:  累計失敗次數

22.      依照上述步驟，繼續完成整張狀態圖，並選擇主選單的【File->Export Diagram】，匯出JPG圖檔，如圖7-39所示。

圖7-39:  狀態圖

7.4-模擬PIM-2：分析企業規則

給SA的UML/MDA實務手冊
----------
第7章-分析企業規則

7.4  模擬PIM-2：分析企業規則

系統分析師經過了PIM-1之後，認為「定期定額申購」是很重要的企業物件，而且涉及許多重要的企業規則，所以決定為它繪製狀態圖，以便組織企業規則，同時也對定期定額申購有更深入的理解。

系統分析師把到目前為止，所獲知跟定期定額申購有關的規則或事項，條列如下。羅馬當然不是一日建成的，狀態圖也是一樣，所以我們還針對每一要項，做如下圖7-11~14所示的片段設計。

1.          約定日一到，系統將自動扣款產生一筆定期定額申購，如圖7-11所示。

2.          連續3次扣款不成功，銀行將自動停止繼續扣款投資，如圖7-12所示。

3.          投資人可以更改扣款狀況，從「正常扣款」或「暫停扣款」二擇一，如圖7-13所示。

4.          正常扣款狀況下，系統才會自動扣款，如圖7-14所示。

圖7-11:  約定日到扣款

圖7-12:  3次扣款不成

圖7-13:  更改扣款狀況

圖7-14:  正常扣款

        接著，我們把上圖7-11~14的片段做合理的組織，組成如圖7-15的雛形。這當然不是唯一的做法，我們只是展示了繪製狀態圖的思考過程，系統分析師絕對有自己獨特的思考過程。

圖7-15:  初步的狀態圖

        系統分析師跟企業人員確認之後，增加了下列兩項事項：

n   首次扣款若未成功，銀行也會自動終止定期定額申購約定，如圖7-16所示。

n   投資人隨時可以終止定期定額申購約定。

圖7-16:  首次扣款未成功

系統分析師修正了定期定額申購物件之狀態圖，如圖7-17所示。

圖7-17:  定期定額申購物件之狀態圖

最後，系統分析師試著執行整張狀態圖，隨後做最後的調整，並產出如圖7-18的狀態圖。調整細節如下：

n   增加「初始設定」狀態，執行交易資料的初始設定、計算交易金額和產生交易編號。

n   「正常扣款」、「暫停扣款」和「終止扣款」三個狀態內部都增加一項「設定狀態」的進入行動。

圖7-18:  定期定額申購物件之狀態圖 

7.3-備妥StarUML

給SA的UML/MDA實務手冊
----------
第7章-分析企業規則

7.3  備妥StarUML

        在正式開始PIM-2的訪談之前，系統分析師記得先備妥StarUML的環境。以「定期定額申購」的狀態圖為例，產生同名之狀態圖的操作步驟，如下：

1.          在「PIM-2:分析企業規則」底下，新增狀態圖(Add Statechart Diagram)，並更名為「定期定額申購」及「定期定額申購」，如圖7-9所示。

圖7-9:  新增狀態圖

2.          新增了狀態圖之後，StarUML會自動備妥如圖7-10的狀態圖繪製環境。隨後，系統分析師便可以一邊繪製狀態圖，一邊進行訪談了。

圖7-10:  狀態圖面及工具箱

7.2-PIM-2：分析企業規則

給SA的UML/MDA實務手冊
----------
第7章-分析企業規則

7.2  PIM-2：分析企業規則

企業規則散落四處；系統分析師可以透過不同的UML圖，重新組織且呈現企業規則，如下：

n   PIM-1的系統UC敘述，以系統流程為主，記錄限制流程的企業規則。

n   PIM-2的狀態圖，以物件行為為主，記錄刺激物件反應的企業規則。

n   PIM-3的類別圖，以靜態結構為主，記錄限制物件種類或結合關係的企業規則。

在進行PIM-1時，系統分析師已經廣泛地記下些重要的企業規則了。接著，系統分析師可以從中找出涉及多項企業規則的企業物件(Business Object)，並於此處的PIM-2，再進一步透過狀態圖，組織且記錄更多重要的企業規則。

        同時，系統分析師經過了建立狀態圖的思考過程之後，可以對重要企業物件的狀態變化更加清楚。系統分析師可以用一張狀態圖呈現某一種重要物件一生的行為。從物件誕生到滅亡期間，它會對哪些事件(Event)有所反應，因而轉換(Transition)其內在狀態(State)，而且執行某些特定的行動(Action)。

針對物件一生中可能執行的一組行動，系統分析師使用狀態來分組這些行動。因此，物件一旦轉換進入某一個狀態之後，其可執行的行動就會被限制，直到發生了重要事件之後，物件才會轉換到另一個狀態，同時也執行新狀態內部規定好的行動。

現在，我們來看圖7-4的狀態圖片段；這是狀態圖最簡單的模樣。狀態圖內有一堆狀態，事件發生時，狀態會遵照轉換線的箭頭方向，轉換到另一個狀態，並且執行狀態內部指定的行動。在基金模擬個案中，定期定額申購交易物件原處於「正常扣款」狀態，當接收到「停止約定」事件時，物件會離開「正常扣款」狀態轉換到「終止扣款」狀態，並且執行「關閉定期定額交易」這項行動。

圖7-4:  事件刺激造成狀態轉換

        物件有兩種執行行動的方式。一種情況是，物件進入狀態之後，執行狀態內部指定的行動，如圖7-5的「扣款」行動。另一種情況是，物件在轉換狀態的瞬間，執行一項不可中斷的行動，如圖7-5的「累計失敗次數」行動。轉換瞬間執行的行動，標示在斜線(/)之後；如果因事件而轉換執行的話，事件標示在斜線前，如「扣款失敗/累計失敗次數」的表示法。

圖7-5:  行動

        轉換行動通常執行時間短暫，有不可中斷的特質；而狀態行動則執行時間較長，而且可能因事件中斷執行，轉換到另一個狀態。系統分析師如果想更明確地指稱兩者，可用「行動」(Action)表不可中斷的動作，以「活動」(Activity)表可中斷的動作。所以，轉換線上的動作稱為行動，而狀態內部的do動作則稱為「do活動」。

有些過度謹慎的系統分析師可能會困惑，某些動作到底是放置於轉換線上好，還是放置於狀態內部佳。除了轉換行動與狀態活動的可否中斷特性之外，似乎沒有更好的區分，更何況，雖說狀態活動可被中斷，也不意味著不可中斷的行動不能放置於狀態內，所以這項特性似乎無助於解決系統分析師的困惑。

這樣的困惑或許只是我的多慮，每個系統分析師都有自己的思維和設計風格。不過，有一種情況我會明確地採用轉換行動。當動作的結果會決定轉換線時，我會明確地採用轉換行動。

請看圖7-5的例子；扣款失敗的事件發生且引發轉換瞬間，物件會執行「累計失敗次數」行動。而累計失敗次數的結果會影響物件選擇下一條轉換線，進入不同的狀態。在基金模擬個案中，定期定額申購物件每月執行一次定期定額自動扣款，一旦連續3次扣款失敗的話，物件會進入終止扣款狀態，並執行「關閉定期定額交易」活動。

轉換線可以置於一般狀態之間，也可以置於一般狀態和選擇狀態(Choice Pseudostate)之間，如圖7-6所示。物件轉換進選擇狀態後，沒有任何指定的活動需要執行，它僅需做一項多擇一的選擇，從多條設置了警戒條件(Guard)的轉換線中，擇一轉換至另一個狀態。

圖7-6:  轉換行動與選擇

狀態內部也不是只能設置do活動，另外還可以設置其他種類的動作，如「進入行動」(Entry Action)和「離開行動」(Exit Action)，如圖7-7所示。在基金模擬個案中，定期定額申購物件在進入終止扣款狀態後，會立即執行「設為終止扣款狀態」的進入行動。隨後，物件會繼續執行「關閉定期定額交易」的do活動，執行完所有的do活動之後，物件就停止了。靜待事件發生，物件才會在轉換離開「終止扣款狀態」之際，執行「電郵終止扣款通知」的離開行動。

圖7-7:  進入行動與離開行動

最後，我們來看物件狀態的起點(Initial Pseudostate)與終點(Final State)，為了方便解釋起點與終點，所以簡化定期定額申購物件的狀態圖為圖7-8的模樣。

在基金模擬個案中，定期定額申購物件誕生之後，將立即從起點狀態進入到「正常扣款」狀態，約定日一到，就進入「自動申購」狀態執行「扣款」活動。一旦累計3次扣款失敗的事件發生，物件會轉換進入「終止扣款」狀態，執行「關閉定期定額交易」的活動，並於執行完畢之後，進入狀態終點。一旦物件進入終點之後，就完全停止了，不會再發生任何狀態轉換的情況了。

圖7-8:  起點與終點