Thinking In UML 讀書筆記（二）擷取需求

定義邊界

以邊界外的業務目标定義系統邊界，就是将系統看成一個整體，暫時忽略系統内的業務期望。

采用業務子產品的缺點就是子產品之間的耦合可能比較複雜，不利于提煉清晰的需求。

第一步讨論

第一個讨論

從業務目标得出的邊界是有明确的理由的，在邊界内可以得出的用力也是有明确的依據的。

假設一個涉衆的工作職責有10個，而其中5個是與業務目标相關的，則系統邊界内隻容納這5個，其他的還是要依靠涉衆自己執行。

第二個讨論

從業務目标的角度劃分邊界，可以得到一個明确的目标，将與目标有關的用例放在邊界内，這樣可以讓業務需求更清晰。

要在業務目标的基礎上劃分邊界，在邊界的基礎上擷取用例。

第三個讨論

不是所有的系統都有業務目标。

如果系統是以計算、控制、自動化為目的的，就很難找到業務目标，但這些系統有明确的功能目标（對于這一點，我表示有異議，很多情況下甲方很難提出明确的功能目标），可以利用功能目标劃分系統邊界。邊界一旦定義，則在邊界外與改邊界有利益關系的一切東西，無論他是人還是物還是系統，都是業務主角，主角對系統提出期望，就是業務用例。

發現主角

一個涉衆可以衍生出多個主角。

涉衆直接與系統邊界發生了互動，則才能成為主角。

擷取業務用例

每一個主角對系統的期望都是系統的業務用例，可以通過查找業務手冊，崗位說明，涉衆分析，涉衆訪談等形式擷取到。

業務用例是比較高層次的業務抽象。

目前比較流行的項目估算方法是工作分解結構WBS，而業務用例就可以作為工作分解的起點。将業務用例分解成小的，易于估算的工作包。小的項目分成的工作包為一個人一周的工作量，大的可以分解成一個人兩周的工作量。工作包的估算可以是經驗、Delphi法，LOC法。

業務模組化

一個完整的業務模型包括：

+ 業務用例視圖

+ 業務用例場景

+ 業務用例規約

+ 業務規則

+ 業務對象模型

+ 業務用例實作視圖

+ 業務用例實作場景

+ 包圖

業務用例場景

描述該業務在實際過程中是如何做的，潘老師的書上主要是利用順序圖，我也覺得順序圖适用于大部分的情況。

業務用例規約

将用例進行文字描述，包含用例名稱、用例描述、執行者、前置條件、後置條件、主過程描述、分支過程描述、異常過程描述、業務規則、涉及的業務實體、涉及的業務實體。

個人感覺潘老師的《軟體方法（上）》對這部分介紹的更具有參考性。

業務對象模型

業務對象模型是對業務用例中涉及的業務實體進行模組化。可以利用用例圖進行表示，将用例進行細化。

業務用例實作場景

業務用例實作場景說明業務執行是如何實作的，是對業務用例場景的補充。

包圖

在本部分，包圖主要用于資訊分類。

領域模組化

1. 假設領域是一個方程類似的東西，則先提取出所有的變量。
2. 周遊所有場景，探尋不同變量之間的互相影響關系，最終繪制出領域模型靜态圖。（可以用順序圖表示）
3. 驗證領域模型

感覺書中這部分的組織不如《軟體方法》講得透徹。

提煉業務規則

全局規則

安全性要求等規則，對大部分業務都适用的規則。

互動規則

互動過程中所涉及的限制性條件的規則，如表單中哪些是必須填寫的。

内禀規則

對象本身具備的，不因為外部互動而變化的規則。如身份證号是15或者18位。

擷取非功能性需求

主要是指可靠性、可用性、有效性（性能、可伸縮性、可擴充性）、可移植性。