為了讓專案開發團隊也可以使用 UML 模型做為溝通的工具，因此微軟在 VS2010 開發工具中，開始加入了「UML 模型專案」。 你除了可以直接建立新的 UML 模型專案外，你也可以將現有的專案程式碼轉換成 UML 模型，以方便程式的重構。 這個範本中支援五種常用的 UML 模型圖。
- Use Case diagrams ：使用案例圖，主要目的是用來塑模出系統的需求(What)。
- Activity diagrams ：活動圖，主要目的是用來塑模各個案例的工作流程(How)。
- Sequence diagrams ：順序圖，主要目的是用來描述問題領域中物件之間互物的情形。
- Component diagrams ：元件圖，以模組化的方式塑模系統的主要結構。
- Class diagrams ：類別圖，描述物件內的詳細資料結構。
建立模型專案
模型專案範本
使用案例圖
目的
「使用案例圖」，簡單的說，就是要描述「誰」可以在系統中執行「什麼功能」的一種模型圖。 所以在設計使用案例圖時，你必須先分析出有哪些不同種類的使用者，以及每種使用者與系統之間的關連性。 如下圖中的例子：
符號
下圖是「使用案例圖」中可以使用的元素：
動作項目（Actor）與使用案例（UserCase）
在 UML 模型中，與系統互動的使用者，稱為一個「動作項目」（Actor）。 而「使用案例」則是用來表示 Actor 為了特定目的所執行的動作。 所以在設計「使用案例圖」時，你必須先分析出有哪些不同種類的使用者，以及每種使用者與系統之間的關連性。
Actor 並沒有跼限只能是「人」。 例如，若每個月１號固定要產生一張報表，那麼這個 Actor 就會是「時間」。 若要發送某個電子郵件，這個 Actor 就會是「系統」。
關聯（Associations）
在 Actor 與 UserCase 之間的線段，稱為「關聯」。 用來描述特定的 Actor 才可以參與這個特定的 UserCase 。
子系統（SubSystem）
有時候系統會參考到外部系統，然而外部系統的設計並不包含在此次開發範圍，這時候你就可以使用「子系統」來識別系統內與系統外的區別。
一般化（Generalization）
Actor 與 Actor
在 Actor 與 Actor 之間，可以建立「一般化」的關係，這東西有點類似繼承的意思。 像下圖中，「非會員」可以瀏覽商品，「會員」才可以訂購商品。 透過「一般化」的關係，我們可以直接描述「會員」繼承所有「非會員」所關連到的 UserCase
UserCase 與 UserCase
UserCase 與 UserCase 之間也可以建立「一般化」的關係，主要用來將若干個相同目的的 UserCase 予以組織化的程序。 例如下圖中，「轉帳付款」與「刷卡付款」都是和付款有關， 因此，你可以先訂出一個「付款」的 UserCase ，再與「轉帳付款」與「刷卡付款」建立「一般化」關係。
包含（Include）、擴充（Extend）
包含（Include）
「包含」用來指出某個 UserCase 涵蓋哪些更詳細的 UserCase 。 例如下圖中，「訂購商品」這個使用案例包含「加入購物車」和「付款」這二個更詳細的使用案例。
擴充（Extend）
「擴充」用來指出某個 UserCase 在某種情況下可以將功能加入至另一個 UserCase 。 例如下圖中，當使用者想要登入網站時，「會員註冊」這個 UserCase 就會擴充「會員登入」這個 UserCase 。
在上面的擴充定義中有提到「在某種情況下...」，這是一個必須要關注的重點。 下圖再舉一個擴充的例子： 這個圖例說明一個管理員，他平常就會執行庫存清點與訂貨二個案例，但是如果在執行庫存清點時，發覺安全存量不足， 那麼他就會執行訂貨這個案例。
成品（Artifact）、相依性（Dependency）
此外，若是其他的使用案例圖或文件可以用來輔助說明 UserCase ，你就可以使用「成品」項目，將該圖表或文件加到使用案例圖當中。 並用虛線的「相依性」來關連 Artifact 與 UserCase 。
使用案例文件
對於每一個使用案例，都應該有一份相對應的使用案例說明文件，該文件可以包含以下項目：
- 使用案例名稱
使用案例的名稱 - 案例簡述
簡要敘述使用案例的目的。例如：此使用案例描述會員如何進行線上訂購書籍。 - 參與角色
例舉參這個使用案例的所有角色。例如：管理者、顧客。 - 前提
使用案例前提，指的是在使用案例被執行前，系統必須呈現的狀態或是角色必須已經執行的動作。例如：會員已經登入到系統。 - 成功條件
使用案例成功條件，指的是在使用案例被執行成功後，系統所可能處於的一系列狀態。 - 失敗條件
使用案例成功條件，指的是在使用案例被執行失敗後，系統所可能處於的一系列狀態。 - 主要路徑
使用案例的主要路徑，主要是用來描述當行為者做了什麼之後，系統應該要用什麼方式來回應處理。- 使用案例應該具體描述什麼資料被傳到了系統，或者系統回應了什麼給使用者。 但是為了避免使用案例的描述太過於冗長，
- 其他路例外路徑
- 詞彙表
活動圖
目的
由「使用案例圖」中，並無法知道每個「UseCase」中的詳細執行步驟，這時候，就必須使用「活動圖」。 所以說簡單講，「活動圖」就是每一個 UserCase 裡頭，實際作業的執行流程，口語中常講的流程圖，就是一種活動圖。。
活動圖不僅僅可以用來描述案例的執行流程，也可以用來說明使用者與系統之間的商業程序，或者類別方法的實作流程。
活動圖中的基本元素就是由「動作」（Action）組成，每個 Action 都是一個使用者與系統互動的工作，在 UML 模型中，使用圓角矩形表示。 而連接這些 Action 的則稱為流程動線（flow edge）。
符號
下圖是活動圖中可以使用的元素：
決策點 and 合併點
- 決策點（Decision）：決策點有一條流程流入、並有多條流程流出，其中，在多條流出的流程中可挑選執行其中一條流程。
- 合併點（Merge）：合併點有多條流程流入、並有一條流程流出。
結合 and 分岐
- 結合（Join）：分岐點有一條流程流入、並有多條流程流出，表示一份平行工作的結束。
- 分岐（Fork）：合併點有多條流程流入、並有一條流程流出，表示一份平行工作的開始。
結合 vs 合併點
結合和合併點，這二個元素同樣都是用來合併多個輸入流程，並產生一個輸出流程。 主要差別在於結合點必須等待所有流進的流程都抵達後，才能進行流程結合之後的工作。 合併點則必須依據流出流程的決策條件，當滿足決策條件的流程抵達後（可能一條或多條），才可以進行流程合併之後的工作。
物件
用來表示一個活動的輸入資料或是輸出資料。
訊號
系統在執行過程中，有時會產生一些訊號，用以驅動其他事件，此時就可以使用「傳送訊號動作」和「接收訊號動作」來表達這樣的概念。
工作流程種類
由 VS2010 工具箱所提供的元素，你可以依據實際需求設計出各種流程樣式的活動圖，依設計方式的不同，大至可分成三類：
控制流程（Control Flow）
控制流程是最常見的一種活動圖，主要用來描述工作流程執行步驟，如下圖：
資料流程（Data Flow）
活動圖除了用來說明工作執行的步驟，也可以用來描述動作之間所傳遞的資料，這時候就會用到「物件節點」。 「物件節點」有個 Type 屬性，可以用來說明資料的型別。
除了可以使用獨立的「物件節點」來描述傳遞的資料，另外也可以由 action 的「輸出連結」與「輸入連結」來描述在動作之間所傳遞的資料。
並行流程（Concurrence Flow）
所謂的「並行流程」，以程式的角度來看，就是建立多個執行序，同時執行多個流程。 在這類流程中，通常會使用到「分岔節點」與「聯結節點」來分割與合併流程。
將活動圖關聯到使用案例中
由以上介紹知道，活動圖是案例圖中，每一個動作項目的詳細步驟。 當設計好一個活動圖之後，如何將它與案例圖建立關連？
- 由檔案總管中，將活動圖的檔案拖放到使用案例圖中的設計區域中。此時 VS 會在案例圖中建立一個「成品」項目。
- 在成品項目的右鍵選單，選擇「加入」→「相依性」。
此時，你只要雙擊「成品」項目，就會開啟對應的活動圖。
順序圖
目的
「順序圖」是用來表示 class、component、subsystem 或 actors 等物件之間的互動關係，由其著重在物件之間互動的順序，以及互動時所要傳遞的訊息。如下圖：
我們可以由上面這張圖，得到以下的資訊：
- ［會員］可以在［線上購物系統］進行［選擇產品］的操作，並且可以重複選取。
- 選擇結束後，系統會使用［同步］方式進行［確認訂單］。在確認訂單期間，系統必須向［供應商］送出［庫存查詢］，以取得［庫存量］，才能完成確認訂單。
- 在確認訂單後，最後會執行［付款］這個程序。
符號
下圖是順序圖中可以使用的元素：
生命線（Lifeline)
在順序圖中有兩個重要的組成元素：「生命線」與「訊息」（Lifeline, Message）。
「生命線」用來代表一個參與互動的類別、介面、元件、動作項目等的實體。 你可以由工具箱中將生命線項目拖放到圖表，或者由「UML模型總管」中，將已經定義在模型中的物件，直接拖曳到圖表中，建立生命線。
由於參與互動的實體，可能會有相同的型別物件，所在生命線上方方塊中所顯示的名稱，預設為型別名稱加上實體名稱。 如果沒有辯識上的困擾，可以刪除實體名稱，以精簡顯示名稱。
在不同的生命線之間，你可以使用「同步訊息」或「非同步訊息」，來描述系統互動方式。
訊息（Message）
「訊息」可以用來表示某個存取方法的API，也可以用來表示二實體互動時所以傳遞的資料。 一般可分成同步與非同步訊息。
- 同步訊息：傳送者（sender）會等收到回應訊息（用虛線表示）後，才會繼續執行下一個動作。
- 非同步訊息：傳送者送出訊息後，不需等待回應，就會繼續執行下一個動作。
圖例請參上圖
合併片段（Combined Fragment）
在順序圖中，若有個訊息，你希望它可以使用迴圈，或者是條件分支，或者加入其他替代項目，這時候，你就可以針對這個訊息建立「合併片段」來加以描述這些情況。 要使用合併片段，你可以先選取該訊息，然後在右鍵選單中，選取［範圍陳述式］，再選取適當的［合併片段］類型。
合併片段共有 12 種合併方式，常用的有以下幾種：
- 選項（Opt）：不一定會發生的序列，您可以在成立條件中指定發生的條件。
- 其他（ALT）：你可以在片段中放入成立條件，表示在何種情況下可以執行該片段。
例如，在點餐外送服務中，僅定使用信用卡付款。 對沒有使用信用卡的人，就可以建立一個「到店取餐」，用來顯示可能發生的替代訊息序列。
- 迴圈（Loop）：根據條件，重複執行片段內容。
- 平行（Par）：每個片斷都可以平行執行。
- 否定（Neg）：此片段中的序列不得發生。 通常用於 Consider 或 Ignore 片段內。
互動使用（Interaction Use）
Encloses a sequence of messages that are defined in another diagram.
例如在本節最上頭的順序圖範例中，「付款」是一個「互動使用」，這表示「付款」可以直接連結到另一個付款順序圖，而不需重複定義。 若要建立 [互動使用]，請按一下[互動使用]工具，然後拖曳跨越您想要包含的生命線。
建立與變更「互動使用」的連結
對於尚未設定連結的[互動使用]物件， 你可以使用建立新序列，直接連結到一個新的順序圖。 或者使用連結至序列，以連結到一個已經存在的順序圖。 若已經設定連結，也可以使用移至序列來變更順序圖的連結。
元件圖
目的
「元件圖」是用來顯示軟體與系統的主要結構，以及彼此之間的相依性。 使用元件圖描述元件時，是不分程式語言的，而且在設計元件圖時，你只需要識別出元件與元件互動的部份即可。
符號
下圖是元件圖中可以使用的元素：
提供的介面（Provided Interface）與必要的介面（Required Interface）
若要表現元件之間的相依關係，你可以加上「介面」的定義。在元件圖中的介面分成二種：
- 提供的介面（Provided Interface）：表示該元件是實作元件，可提供其他元件叫用。
- 必要的介面（Required Interface）：表示該元件必須叫用其他元件。
若要設定介面的類型，你可以先點選在元件旁的
按鈕，然後選取「轉換為需要的介面」和「轉換為提供的介面」來切換類型。
下圖中，「WebSite」是個「介面」，用來表示「瀏覽器」元件與「線上購物系統」元件之間溝通的介面。 而且，在「瀏覽器」端包含一個「必要的介面」，而「線上購物系統」端則包含一個「提供的介面」。
類別圖
目的
「類別圖」是用來說明程式內部物件的資訊結構。 它只是透過物件的觀點，用來和使用者進行溝通用的說明資訊，與實作類別並沒有直接無關。
一個系統牽涉的類別可能成千上百，不過，它大至可以被分成以下幾個分類：
- 領域問題類別：與領域問題相關的類別
- 商務邏輯類別：與處理商務邏輯相關的類別
- 介面類別：與使用者介面相關的類別
- 資料存取類別：用來做資料存取的類別
- 抽象化概念
符號
下圖是類別圖中可以使用的元素：
類別圖中的每一個類別，都是由名稱、屬性、作業（Classifier, Attribute, Operation）所構成。如下圖範例，
類別關係
在類別與類別之間，你可以在類別圖中使用以下元素來描述實體之間的關係：
關聯（Association）
關聯性（Association）
你可以透過「關聯」來描述兩個 Classifier 成員之間的關聯。 「關聯」使用實線加上箭頭來表示，來源端是負責維護關係的類別，箭頭端是對象類別。 Multiplicity 是連接線上的數字，表示二個類別間，參考這個關係的數量。
反身關聯（Reflexive Association）
同一個 Classifier ，你也可以建立關聯，表示相同類別中的物件之間彼此的關係。
關聯的多重性（Multiplicity）
在建立關聯時，你也可以在連接線上，使用「多重性」來表示二個類別間，參考這個關係的數量。
例如你可以在多重性中使用「*」表示連結數目沒有上限。如下圖中，部門與員工之間為一對多關係。
連接線離自己class比較遠的數字，表示自己class和對方class之間的關係數。 例如下圖表示， 一個部門可以有多個員工，而一個員工只可以有一個部門。 另外，一個員工可以參加1~4個社團，而每個社團由1到多個員工組成。
在建立關聯線時，常見的問題是，這個箭頭方向應該由誰指向誰。 一般來說，若是一對多關聯，大都由一指向多。 因為你可以在類別中，使用array或collection型別的屬性來實作這個關係。 但這並非絕對，實際上要看看，到底要由誰來維護這個關係。 有些 UML 軟體，就直接加上 stereotype 字樣，來表示負責維護這個關係的類別。
多重性表格：
| 名稱 | 表示法 | 例子 |
|---|---|---|
| 恰好一個 | 1 | 班級與班長關係 |
| 零或多個 | 0...* | 班級中姓陳的同學數|
| 一或多個 | 1...* | 學生主修一個或多個學位|
| 零或一個 | 0...1 | 教師有一個或零個計畫補助 |
| 指定範圍 | 2...4 | 職員一年可享二到四個假期 |
相依性（Dependency）
當二個 classifier 物件彼此間具有相依性，你可以使用虛線箭頭來表示。 這表示如果箭頭端的 Classifier 改變，相依 Classifier 的定義或實作可能也會變更。
修改連接關係
在類別圖中，若你想變更二物件的連接關係，你可以先點選「連接器」旁的
按鈕，然後選取「轉換為關連」和「轉換為相依性」來切換連接關係。
一般化（Generalization）
所謂的「一般化」關係，指的就是「繼承」關係。 繼承會從「一般類別（gengeral classifier）」衍生出「特殊類別（specific classifier）」。 「一般類別」位於連接器的箭號端，而「特殊類別」會繼承一般類的屬性、關聯和作業。
整體與局部（Whole-Part）
在類別圖中，可以透過「彙總（Aggregation）」與「組合（Composition）」來描述整體與局部的關聯。
彙總（Aggregation）
「彙總（Aggregation）」關係表示一個「整體（Whole）」是由許多個「部分（Part）」所組成，但是「部份」與「整體」是可以分割的。 Aggregation 另一個常見的翻譯為「聚合」。
彙總的連接線中，一端使用空心菱形來表示 Whole，另一端使用箭頭表示 Part 。 例如下圖中顯示，部門是由員工所組成，不過若部門不存在了，員工還是員工，可以安排到其他部門。
組合（Composition）
「組合（Composition）」關係也是表示一個「整體」是由許多個「部分」所組成，但是這裡的「部份」與「整體」是不可脫離的。
如下圖，訂單是由訂單明細所組成，若沒了訂單，訂單明細就沒有意義了。
建立類別圖
建立類別（Classifier）
要在類別圖中加入類別，除了可以直接由工具箱中將類別項目拖拉到圖表中，也可以由順序圖中，在生命線上按右鍵，再從快捷選單中選取「建立類別」或是「建立介面」。
在分析階段建立類別時，可以只寫出類別名稱，而在往後的計劃進行中，再慢慢找尋出類別的相關屬性和操作方法。
之後就可以由「UML模型總管」中找到新建立的類別或介面。
建立封裝（Package）
你可以將數個 Classifier 放在一個組別內，這個組別在 Visual Studio 的UML模型專案中就稱為封裝（Package），或者稱為類別庫。
在封裝內的物件，其物件的 Qualified Name 會變成包含封裝名稱，用以和外部的物件有所區別。
封裝內的物件，在「UML模型總管」中，也會變更到該封裝之下。
產生程式碼
若是畫好了UML的類別圖，VS2010可以直接分析類別圖中的內容，幫您產生對應的程式碼框架。 不過這個功能並不是內建並的，使用前需另行安裝Visual Studio 2010 Feature Packs才可使用。 下載網址（僅適用於 MSDN 訂閱者）。
物件導向語言中的關聯關係
以上提到類別與類別的各種關聯關係，當看到這樣子的圖表時，在物件導向程式語言中，它們又是如何被呈現的呢？
- 關聯：屬性成員。
- 彙總：不用同生死屬性成員
- 組合：強調同生死的屬性成員
- 一般化：繼承
- 相依：類別中參照其他物件類別。
- 具體化：介面
aggregation和composition在程式語法結構中，比較看不出差異，充其量就是實作 composition 時，要在主類別的distructor中，將關連屬性物件同時delete；而實作 aggregation 則不用。 如果要實做這二個關係，比較重要的實際的資料狀況。 例如，當你新增一筆訂單主檔資料，你必須同時建立訂單的明細資料。同樣的，當你刪除一張訂單主檔資料時，你就會同時刪除該訂單的明細資料。 而實作 aggregation 時，就沒有這個要求。
沒有留言:
張貼留言