1 前言

承接上一篇” 物件導向系統分析與VSTS2010”，我們將需求拆解成Use Case，再針對Use Case用Activity Diagram做動態描述，用Blueprint與Data Glossary做靜態描述，重點在於了解客戶要的是什麼。接下來針對這些客戶需求，我們要轉換成產品需求，即如何設計系統得以實現，所以系統設計文件的目標使用者就不再是客戶，而是開發人員，要如何讓開發人員容易了解我們所要的，這就是系統設計的重點—我們的語言必須接近開發人員。

2 流程

筆者簡略整理OOSD流程分為下列三大步驟：

 

圖1 OOSD流程圖

1.1 找出Entity Class

第一個步驟就是找出Entity Class，即是否有資訊需要儲存，承續上一篇計算器範例，，假設我們需要儲存所有的運算過程與結果，許多書或專家會建議用Class Diagram來表示這一部份，筆者有不同的看法，筆者認為過去用在結構化分析的工具—ERD(Entity Relationship Diagram)還是最好用，其實在系統設計階段，我們必須決定要用什麼儲存方案，如那一種資料庫，再次假設我們選擇的是MS SQL Server，在SQL Server Managerment Studio有提供好用的介面來設計，如下圖：

圖2 Database Diagram

完成後，您可以在VS新建一個Database Project，然後選 Menu -> Data -> Schema Compare，將新建的資料庫Schema匯入Database Project，以納入版本管控。

圖3 Schema Comparison

圖4 Database Project

1.2 找出Boundry Class

Boundry Class即為與Actor(使用者或外部系統)接觸的Class，簡單地說就是使用者介面部份，這一部份筆者認為沿用系統分析的結果即可，因為有可能在考量所採用的架構解決方案，會導致介面改變，如在系統分析階段，我們直接採用舊系統畫面來調整，舊系統是Client-Server架構，但是到了系統設計階段，我們決定採用Web介面，因此勢必有些畫面必須再調整過。

圖5 Blueprint範例

編號	欄位名稱	長度/型態	鍵值	允許Null	規則	範例
1	被運算欄位	int				2
2	運算子	char(1)			下拉選單，值有”+”, ”-“, ”*”, ”/”	+
3	運算欄位	int				3
4	結果欄位	int				5

表1 Data Glossary範例

1.3 找出Control Class

Control Class主要負責商業邏輯部份，它連接Boundry Class與 Entity Class，筆者認為我們可以把系統分析的Activity Diagram加以衍伸，用Sequence Diagram表示程式動態流程，用Class Diagram表示程式靜態結構。兩者其實彼此密不可分，且十分接近程式碼結構，所以很適合用在系統設計。程式靜態結構可以分成兩部份，第一部份資訊需要永久儲存，即前述的Entity Class，另一部份為暫存資訊以及Method結構，此一部份可以用VS的UML Class Diagram來表示，它不同於VS2008之 .net Class Diagram，只能存於Modeling Project，且不提供程式碼雙向互動功能，筆者從MSDN得知目前Beta2版本並沒有產生程式碼樣版功能，也許正式版會有提供。

在UML Model Explorer裡，對”Module1” Package按右鍵選 Add -> Class，以新增我們所要的類別，並加入對應的Operation(Method)，如下圖：

圖6 在UML Model Explorer新增Class

請在Solution Explorer之 DemoModeling -> Module1，新增一 UML Class Diagram，名為” Calculation.classdiagram”，並將上述Class 拖曳至此Diagram，如下圖：

圖7 UML Class Diagram範例

靜態結構完成後，接下來描述動態部份，在Solution Explorer -> ModelingProject -> Module1，新增UML Sequence Diagram，名為” Calculation.sequencediagram”，接著將”User” Actor、”CalculationUI”、”CalculationLogic”等Class拖曳進來，透過Message將其連接起來，Message之Operation是可以從Class中挑選，不過我們無法透過Message之Operation新增Method回Class，完成後如下圖。通常Sequence Diagram用於交代一連續程式流程，所以比較複雜的Use Case可能會對應多個Sequence Diagram，筆者有時為了簡化，會在同一Sequence Diagram表達多個簡單情節，在最左邊用註解標示。

圖8 Sequence Diagram範例

在Method定義出來後，最後透過UML Class Diagram -> Operation之Description屬性，我們可以將操作描述，即程式細部邏輯記錄於此，如下圖。

圖9 Operation操作描述

2 與Work Item的結合

完成後的類別可以連接回原先User Case對應的User Story，在UML Model Explorer裡，對Class按右鍵選 Link Work Item，再查詢出所要的User Story勾選起來即可，如下圖，如此透過User Story，我們就能夠管控相關的文件。

圖10 Class連結Work Item

3 結語

依筆者習慣在設計Class Diagram與Sequence Diagram，會互相交疊，目前的版本只能先靜態，再動態，會比較不方便一點。

產生程式碼樣版，目前在MSDN上只看到標題” How to: Generate Code from a UML Model”(http://msdn.microsoft.com/en-us/library/ee329480(VS.100).aspx)，只能猜透過API存取Diagram，自行客製程式碼樣版。雖然很多人很關注這一功能，但筆者認為它不是很重要，UML頂多只能做到程式樣版，其實樣版自己手動輸入不用一天也搞得定，真正難搞的是後續的實作邏輯，這裡UML幫不上什麼忙。筆者認為終極解法是DSL(Domain Specific Language)，在此提供過去一些心得供參考(http://cid-937b32874d1644f9.profile.live.com/Lists/cns!937B32874D1644F9!226/)。

本文採用OOAD方法論參考自中山大學吳仁和老師的方法論(http://www.bestwise.com.tw/user_book_data.asp?sel_serial_id=1416)。

若讀者有興趣想詳細了解如何導入此方法論，可以洽詢鼎升資訊科技(http://www.dands.com.tw/products/ai.htm)，他們有提供導入服務。