在經過了幾天幾夜的猛K狂查之後，大爺終於對UML的使用案例圖 (use case diagram)有了一點點初步又深入的瞭解。不過這邊整理的是，大爺在看了不少的UML書籍和網路上的資料後，遇到的問題所做的思考，當然希望這些結論是正確的，不過如果有錯的話，還麻煩指點一下小弟，感溫。
UML發展至今應該也超過10年了吧。市面上大大小小教導UML的書籍一堆，不過真要把這些書都看完也不是那麼容昜的。就目前手上的書籍和網路上看過的資料來說(目前看的都是以中文網站為主，英文方面的資料還是等看完中文再來研究吧 @@)，感覺很多都只是沾到皮毛，真有說的清，講的白的，目前還沒看到。而且每個人的觀點都不同，最慘的是遇到剛好反相的觀點，這實在是叫我看的頭昏眼花，也不知道該聽誰的。
舉例來說好了：
在網路上找到的「UML系統分析與設計」這本書解答的投影片(第5頁)和「使用案例圖 UseCase Diagram」這個投影片，裡面都提到。使用「CRUD」 (Create 建立 retrieve讀取 更新Update 刪除Delete )」來找出使用案例。
不過在另一本「UML 理論與實作 - 個案討論與經驗分享」這本書卻在第四章(p.108頁)提到，儘量避免採用「AUDI (ADD Modify Delete Query) 」的方式來思考並找出使用案例。
鄉親啊!不論是CRUD還是AUDI，在中文來說不就都是講同樣的東西嗎，新增、修改、刪除、查詢。你看看，這樣怎叫人不頭昏眼花，我還真想找這些作者來PK一下，看看到底是誰說的比較正確 = ="。
(或許是大爺才疏學淺沒搞清楚作者們的看法吧，大爺會再仔細的研究到底是怎麼一回事。)
但如果依照大爺本身的觀點來看，我會比較偏向選擇後面這本書的觀點，也就是儘量避免採用「AUDI (ADD Modify Delete Query) 」的方式來思考並找出使用案例。有興趣的鄉親可以翻翻這本書，這位作者有提供關於他這個論點的說明，個人覺得值得參考、使用。
不過我想UML只是個工具，工具書還是直接看官方文件應該會比較準確吧，只是官方文件跟天書沒兩樣，真要能看完和瞭解的話，我應該也能出一本書了吧。@@
以下就是目前遇到的問題，和我自已的一些想法，有錯請告知，感溫：
1.案例與案例之間的關係，案例與案例是否俱備層次關係? 空箭頭連接線是表示一般化關係，還是案例與案例之間的層次關係?
根據我在網路上找到的一個投影片教材裡面提到，使用案例圖中也可以
表示一般化關係，使用案例的一般化關係與物件導向語言的一般化關係
是類似的概念。在使用案例圖中，ㄧ般化關係可以被應用在：
* 角色的一般化以及
* 使用案例的一般化
角色的一般化 (繼承的概念)
假設我們從需求分析中發覺了甲、乙兩個角色，並且我們從需求描述中
分析出乙角色不僅可以參與甲角色的使用案例，乙角色還可參與其他的
使用案例。這種情形我們可以塑模如下：
此圖說明甲角色參與使用案例1、2，而乙角色不僅可以參與使用案例1、2，並
且還可以參與使用案例3，因為乙角色延伸了甲角色，因此乙繼承了甲可以參與的使用案例。
使用案例的一般化
範例1：以一個訂票系統來說，顯而易見地， 」訂票」是一個很容易捕
捉的使用案例。若細分訂票方式的種類，那麼訂票的方式可能是打「電
話來訂票」，或者是直接「在網路上訂票再來取票」。
<<essential>>
這個使用案例圖說明了」電話訂票」以及」網路訂票」在本質
(essential)上都是訂票。所以可以使用一般化來塑模這些案例。並且在
父使用案例加上<<essential>>這個stereotype來表明這個一般化的
關係。
範例2：執行ATM交易
一個ATM系統有「執行ATM交易」使用案例。自動提款機所提供的交易
服務項目中包含提款、轉帳、查詢餘額等，因此，我們可以利用一般化
的關係來細化「執行ATM交易」使用案例。
結論：如果依照這位仁兄(很抱歉，我只找到這個投影片，也不知道作者
是誰，是參考那本書。很不負責任吧 = =") 的看法，那空箭頭的連接符
號就能用在表示「案例與案例的層次之間」和「角色一般化(繼承的關係
)」上面，我是覺得這個說法應該是正確的啦，不過一些書上面把這個使
用案例的一般化也稱作為是繼承。
這樣很容昜讓人搞混，因為在程式的定義來說繼承是指子類別繼承了父
類別的方法和屬性。可是如果依上面的範例來看，子案例不能說是繼承
了父案例，應該是包含在父案例裡面比較妥當吧。這方面大爺還會再多
翻翻其它的資料。不過UML也只是個表示法，只要能在溝通的時候解釋
清楚就OK了。我想這也只是說法不同罷了。
2.無箭頭連接線、實線箭頭連接線與虛線箭頭連接線表示的關係。
又是連接線的問題，這真是令人捉摸不定的東西，不過基本上使用案例
圖就是由這幾個基本的元素所構成的，應該搞懂的話就能畫出比較像官
方所說的使用案例圖了吧。(在這邊我不用「正確的使用案例圖」這個名稱來敘述，你想想，連書上的觀點都能相反了，那還有分什麼正確還是錯誤哩)
實線箭頭和無箭頭連接線，這兩條線是將動作者和使用案例連結在一起的。如果是實線箭頭則是表示「通訊的方向」，如果通訊的
方向是雙向的話，那麼可以在兩端都放上箭頭，也可以不加箭頭只加實現。這麼一來就很清楚這兩個箭頭的用法啦。
這二條線是比較好懂的，也沒什麼問題，再來讓我們看看有問題的一條線吧，虛線箭頭。
虛線箭頭，表示「案例與案例之間的關係」，在目前讀過的資料來看，最主要是分成「include」和「extend」這兩個相依關係記號。也就是說在用到這兩個案例時，連接線會用到虛線箭頭。
不過最主要的問題是這個「相依關係記號」的使用法，也就是像「include」和「extend」這樣子的相依關係記號。然而這邊的問題有兩個，目前還在想辨法找尋答案中，不知道有沒有高手可以幫幫忙的。
這個「相依關係記號」和 「stereotype(UML擴充詞彙)」是同樣的東西嗎?
這個「相依關係記號」可以用自已的名稱來定義嗎，還是只有include和extend這兩個相依關係記號?
3.stereotype(UML擴充詞彙)是所有的圖都可以使用，還是用在固定的某些圖檔中。
這是上面有提到的「相依關係記號」問題的延伸，在網站有找到討論「UML擴充詞彙」的文章 ( http://www.blogjava.net/kapok/archive/2005/06/10/5846.html )。
裡面是有提到關於如何新建自已的UML擴充詞彙。UML的擴充性機制允許你在控制的方式下擴充UML語言。這一類的機制包括：stereotype，標記值、約束。
很好，光是stereotype就搞不太清楚了，現在又來了2個新同學 -- 標記值、約束。這不是讓人更迷糊嗎，所以我說很多UML的書籍
提到的都只是皮毛，真讓我覺得是來騙錢的 (騙錢這話是開玩笑，別當真)。
而且在這篇文章內又有提到UML中的四種機制使地它簡單和更易於使用，你可以在UML語言的任何時候用同樣的方法來使用。
這四種機制是：
specifications
adornments
common divisions
extensibility
很好，這下新同學又增加了四個，雖然科南同學說真相只有一個，不過
這下子想要搞懂UML的全貌非得花上不少的時間。不過依我的觀點來
看，這些應該都已經算是UML的進階概念，一般應該比較少用到。等
我搞懂應該也能來考張UML的 證照了吧。所以，先跳過這一部份吧，
下次有機會再去把市面上有的UML書籍都找來翻翻看吧。
留言列表
