物件導向分析與設計學習（一）

OOA&D的第一步，就是瞭解使用者需求，並將其轉換為業務使用案例圖

這裡要注意三點：

1、業務用例僅從系統業務角度關注的用例，而不是系統提供的用例，業務用例關心“系統該實現什麼業務”而不是“系統提供了哪些功能”；

2、業務用例僅包含客戶“感興趣”的內容；

3、業務用例中所有用例必須是客戶能夠看得懂的用例，如果該用例客戶看不懂，那麼他就不適合做為業務用例。

OOA&D的第二步，就是為業務使用案例圖中各個用例繪製活動圖表

活動圖表描述了這個業務用例中，使用者可能會進行的操作序列。活動圖表有個很重要的使命：從業務用例分析出系統用例。

OOA&D的第三步，就是從活動圖表中選出系統用例

找出所有的備選系統用例後，我們要對他們進行合并和篩選。合并就是將相同的用例合并成一個，篩選就是將不符合系統用例條件的備選用例去掉。
一個系統用例應該是實際使用系統的使用者所進行的一個操作

OOA&D的第四步，就是根據系統用例設計使用者規約

用例規約唯一的要求就是“清晰易懂”

OOA&D的第五步，就是繪製業務領域類圖

完成了上面幾步，下面應該是繪製業務領域類圖了。所謂業務領域類圖要描述一下三點：

1、系統中有哪些實體；

2、這些實體能做什麼操作；

3、實體間的關係。

這裡要特彆強調：這裡的實體不是Actor，而是Actor使用系統時使用的所調用的實體，是處在系統邊界之內的實體。

理解以上這段話非常重要，我經常看到由於混淆了實體和Actor的關係而導致畫出的領域類圖不準確或職責分配不準確。
大家可能還注意到，我們這裡沒有給出每個實體的屬性。其實，在領域分析階段，實體的屬性並不重要，重要的是找出實體的操作。

OOA&D的第六步，就是繪製實作類別圖

以上這幾步，就是分析的過程。而下面的步驟就是設計了。
1、設計沒有分析那麼好描述，因為分析是“客戶面”，它只關心系統本身的功能和業務，而不關心任何和電腦有關的東西。但是，設計和平台、語言、開發模型等內容關係緊密，因而很難找出一個一致的過程。但是，一般在設計過程中實作類別圖是要繪製的。
2、實作類別圖和領域類圖不一樣，它描述的是真正系統的靜態結構，是和最後的代碼完全一致的。因此，它和平台關係密切，必須準確給出系統中的實體類、控制類、介面類、介面等元素以及其中的關係。因此，實作類別圖是很複雜的，而且是平台技術有關的。

OOA&D的第七步，就是繪製順序圖表

有了靜態結構，我們還要給出動態結構，這樣，才能看清系統間的類是如何互動的，從而有效協助程式員進行編碼工作。
順序圖表在實際中是很多的，幾乎每個類方法都配有相應的順序圖表。