宣告：本用例圖的構建採用哲學家就餐問題中的服務生方法，即哲學家欲想吃飯，需委託服務生為其代勞。

預先準備：正所謂：“工欲善其事必先利其器”

繪製UML的必備工具如下：（任選其一即可）

1，最簡單的 線上繪製UML圖 ProcessOn  網址：www.processon.com

2，Visio 非常全面，比較雜，支援各種圖，我記得大一下學期的時候，交C語言大作業——一個簡單的學生管理系統。當時的代課老師就是用的Visio讓我們畫圖，挺好的老師，好像就是從那個時候和我前女友稍微認識的，啊，一晃都過去六七個月了，我都大二了。

3，Rational Rose 最開始便是為UML而生 後來加入對資料庫的建模支援 和PowerDesign剛好相反。

4，PowerDesign 對資料庫的支援比較好。

建議初學者（我就是其中一個）用第一個線上網站 比較方便 用著也很舒服，我覺得做產品也應該是這樣，讓人舒服的東西才叫好東西，不是簡簡單單的滿足了我的需求，PonyMa之所以可以很成功的建立 騰訊，在很大程度上他是以產品經理的角度上去思考問題的：“Don’t  make me think”,便是他的觀念之一。

導言：

關於UML,我最近主要在看兩本書，

一本是偏向實戰《大象 Thinking in UML》，這本書是以實戰的方式來講述如何去在是實際業務中去充分利用UML。

另一本是UML發明者之一的Michael Blaha的《Object-Oriented Modeling and Design with UML》即《UML 面向物件建模與設

類建模及高階類建模，類模型表示系統靜止的，結構化的“資料”層面，

類圖，描述了系統內部物件及其關係的靜態結構。

狀態建模及高階狀態建模，狀態模型則是表示系統時序的，行為的控制層面，

狀態圖，描述物件隨著時間發生變化的哪些方面

互動建模及高階互動建模，表示各個物件的協作，是系統的交流。

用例圖，關注系統的功能，強調系統為使用者做了什麼事情。

順序圖，顯示互動的物件以及發生互動的時間順序。

活動圖，描述重要的處理步驟。

仔細想想，其實就能看出來個端倪，以面向物件的角度來看的話，類模型就是建立一個類，表明我創造出來一個我準備用的東西

狀態模型就是，在不同的時間順序下，我的這個東西要去做些什麼事，互動模型就是，我的這個東西去和別的東西去發生交流溝通，資料傳輸和控制。

我到現在覺得面向物件，實際上就是看待世界上的東西只有我本身和無數個不同的“你”打交道。只需要這三個模型便可以概述出幾乎所有的事情。

大致介紹就到這裡把，扯得有點多。

用例圖   ——正式開始！

用例圖是描述系統如何與外部參與者互動的圖。他從使用者角度描述系統的靜態使用情況，用於建立需求模型。          

通過上面的話，其實用例圖的中心其實已經就凸顯出來了，外部參與者+系統——>（互動) = 用例圖 

用例圖的元素 參與者（Actor），用例（Use Case）, 關係（Relationship），邊界（Boundary）。

第一彈：參與者

• 參與者可以是人或其他外界系統。參與者只是一個角色而不是具體的人，它代表了參與者在與系統打交道的過程中所扮演的角色。只要你承擔了參與者的人物，做到了參與者應該做的事情，那麼不論是什麼，都可以叫做參與者。
• 參與者是用例的啟動者，參與者驅動用例進行，因為參與者的驅動，系統才會開始工作，系統因而才有了存在的意義，但參與者本身並不是系統的一部分。我記得小時候的拖拉機（大型卡丁車）的啟動就是用一根大鐵棍去啟動的，拖拉機動起來是因為人想拖拉機了，但人不是拖拉機的一部分。
• 參與者可以參與多個用例，我們可以假想參與者是一個人，那麼他不僅可以去銀行存錢，也可以去超市買東西，對吧。

參與者長得就是這個樣子，一個火柴人~

可是光知道籠統的概念是不夠的，如何才能去發現我們所做專案的參與者呢？這個才是關鍵部分。

於是有引出了一個不在用例圖元素之內卻很關鍵的一個東西——涉眾

涉眾（Stakeholder）涉眾是與要建設業務系統相關的一切人和事，參與者是涉眾的代表，他代表著涉眾對系統的利益需求，系統是以參與者的觀點來建立的，因為參與者有這樣的需求便有了這樣的一個系統，比如哲學家就餐問題中的涉眾，無非兩個，哲學家，和服務生。我對此琢磨了好久究竟要選誰作為參與者比較合適，最終我選擇了服務生，為什麼呢？我一直在想這裡的主角是哲學家還是服務生，

如果是服務生，那麼明明是哲學家發出的請求，不應該是哲學家作為參與者嗎？

如果是哲學家，可是服務生在該系統中承擔著溝通交流的人物？

在不斷的糾結之下，我選擇了服務生作為參與者，因為就問題的最本質而言，無非是對系統發出資源的請求，如果採用逆向思維的畫，我們會發現服務生在此刻是離系統最近的，其次才是哲學家，也就是說，一定是服務生與作業系統建立起資源請求的聯絡，然後服務生和作業系統構成的整體在作為一個系統和哲學家產生聯絡，這是一個巢狀的關係。對此我用一個用例描述就很清晰了。

第二彈——用例

用例是系統外部可見的一個系統功能單元。系統的功能由系統單元所提供，並通過一系列系統單元與一個或多個參與者之間交換的訊息所表達。用橢圓表示，橢圓中的文字簡述系統的功能。

參與者與系統的各種互動均可被量化成用例。其實用例就是由於參與者的存在而引發出來的事件，有多少事件就有多少用例。

橢圓裡面便是用例事件。

第三彈——關係（該圖片來自百度）

關聯(Association)表示參與者與用例之間的通訊，任何一方都可傳送或接受訊息。【箭頭指向】：指向訊息接收方

泛化(Inheritance)就是繼承關係，子用例和父用例相似，但表現出更特別的行為；子用例將繼承父用例的所有結構、行為和關係。子用例可以使用父用例的一段行為，也可以過載它。

 包含(Include)把一個較複雜用例所表示的功能分解成較小的步驟。

擴充套件(Extend)擴充套件關係是指用例功能的延伸，相當於為基礎用例提供一個附加功能。

對於關聯關係是最基礎的關係，用於通訊，一般來說只要不涉及其他的關係，關聯關係應用是最多的，

泛化關係的英語單詞就是繼承的意思，父類和子類的關係，比如喝東西這個用例 可以包括 喝水，喝咖啡，喝茶。由於我的觀點所處理的哲學家就餐問題中沒有體現到該關係，於是我用了喝東西這個事件來解釋。

。

包含關係:是為了解決複雜化的問題，將一個複雜的用例弄得簡單就是該關係存在的意義。比如上上圖中的叉子檢測問題，就比較複雜，它包含了兩個小的用例，一個是叉子數目滿足需求，另一個是叉子數目不滿足需求。此時便要用到包含關係，來簡單化該用例。

擴充套件關係在我看來是屬於平級的關係，附加補充的他的職責，比如當服務生給與叉子或否時，接下來還要做些什麼事情。

前面已經說了，這個問題在我看來有巢狀的成分，所以以上的系統應該叫做服務生管理系統，然後用該系統作為一個用例，和哲學家一起構造出哲學家就餐問題系統。其實這裡就延伸出另外一個問題，當初糾結於誰作為參與者的時候其實就是因為邊界的定位不夠清晰，“界”在哪裡，這是個極其抽象模糊的概念，最終我從問題的最裡最本質的角度反向思考，就像圓一樣，我不清楚我所在的位置，那我就去找圓心，通過圓心去找這個圓心有幾個同心圓，誰離得最近，發現是服務生，然後是哲學家，如此一來，邊界便一清二楚。整個問題也就簡單了。

思考：其實這個問題並不難，我覺得學長的意思是想拿哲學家就餐問題來讓我練練手，一邊學習作業系統的知識，一邊學習下架構的思想，一舉兩得，站在一定的高度上去看待問題對以後的成長之路還是很有幫助的。可能哲學家就餐問題確實不是一個比較好的uml問題，但是重點並不在這裡，當我們對一個問題去思考的時候，便會把我們的所學所得和缺少遺漏的東西去補全，而且，世界上哪有十全十美，恰好合適的東西，以後使用者提需求的時候，也不一定會完整的把需求列舉出來，還是要自己去補充，思考，提升學習能力，這個也是我在看的另一本書（另一篇帖子《程式設計師的九堂課》）所理解到的，這個才是重點，就是這樣啦~

以上便是我用模型觀點來看待的哲學家就餐問題的思路，如有不同意見，歡迎討論。國慶第二天，還沒玩夠，寫個帖子沒想到要花這麼久，打會遊戲，放鬆放鬆~

享受美好的假期生活。

思念我的女朋友，前女友。看她朋友圈發的旅遊的動態，我很不舒服，想打人...

2018.10.02.17：48