《UML 精粹》讀書筆記。讀的是老版，可能和你瞭解的有一些語法上的不一致
UML 全稱爲統一建模語言，它不是一種方法，而是一種語言，跨越了具體編程語言的限制，以其當前狀態定義了一種表示法和一種元模型。
爲什麼需要 UML
首先需要明白一點，任何一種工具的出現都是爲了解決某個實際問題的，而這個工具自身的生命力還很強，那就說明它解決問題的效果很棒，至少當前沒有找到比這一工具更有效率的替代物。
軟件開發最大的挑戰是構建正常的系統，即滿足用戶且價格合適的系統，這看起來是很容易的事情，但實際做起來卻相當困難，我們必須用我們熟悉的行話與用戶溝通，而用戶卻使用他們自己更爲神祕的行話（比如醫療術語等），所以實現良好溝通乃是開發良好軟件的關鍵。
UML 就是要解決此前面向對象設計方法中表述不嚴謹、溝通效率低的問題。如果我們使用自然語言來描述某個比較複雜的概念，很容易就會引起大家的困惑，可能自然就想到相應的代碼是非常精確的表述，但是又過於詳細了。因此，當需要一定程度的精確性同時又不失掉細節時，UML 便是非常好的選擇。
概要開發過程
UML 是一種建模語言，但是如果不瞭解建模技術如何適應過程，那麼建模技術也就不會有絲毫的意義了，UML 是獨立於過程的，它可以適用於任何過程。
一個軟件的開發過程中大致會遇到四類風險。1、需求風險：你將開發一個錯誤的系統，壓根就不是客戶想要的系統；2、技術風險：如何把各個設計成分組合在一起（比如 C++ 和數據庫）；3、技藝風險：能否得到所需要的工作班子及專門的知識；4、政治風險：存在可能妨礙並嚴重影響項目的政治力量。
針對需求風險，我們可以通過用例來驅動開發，但是需要注意的是，用例並不是整個形象，所以另一個重要的任務就是提出領域概念模型，爲了防止開發出錯誤的系統，需要經常和領域專家進行溝通，去熟悉領域的專業知識，同時能獲得很多的用例也是關鍵。
最大的技術風險在於如何把各個設計成分組合在一起，比如你很瞭解 C++ 和關係型數據庫，但是把它們放在一起的時候就很難保證不出問題，所以在設計時可以給自己提一些問題：如果技術的一部分不能工作，將要發生什麼？某件事做錯的可能性是什麼？如果錯誤發生，將如何應對？
應對技藝風險最切實可行的辦法就是組織讀書小組，幾個人讀同樣的一本書，約定每週讀幾章，然後花一兩個小時討論，這是很有效的一個模式。同時自己也需要放開眼界，留意自己在技藝或經驗不足的方面。如果有一個知識淵博且妙趣橫生的人作爲導師，那即使付一筆酬金也是值得的，獲得面向對象技藝的最佳辦法就是導師指導。
技術人可能對付政治風險都會乏力，最簡單的辦法就是消除領導的不確定性，給領導制定一個詳細的迭代計劃，辨認出所有的重要風險並且知道如何應對這些風險。簡而言之就是給領導呈交一個詳細的計劃表。
用例圖
不管是在面向對象或是傳統開發界中，人們都使用典型的交互來幫助瞭解需求，通過用戶使用場景去獲取需求，用例就是以文本形式從用戶角度描述系統的行爲，爲了使用例更加形象化，Jacobson 也引進了用例圖，它是用來描述參與者與用例以及用例與用例之間關係的圖，即```用例圖 = 參與者 + 用例 + 關係。
上文公式中已經給出了用例圖的基本元素，即參與者、用例和關係。參與者是用戶相對於系統而言所扮演的角色，雖然我們都會把參與者畫成一個小人的形狀，但它不僅它可以是人，也可以是其它外界系統，並且每個參與者可以參與一個或多個用例，參與者是用例的啓動者，需要要注意的是參與者並不是系統的一部分。
參與者與用例之間有天然的關係，除了這種關聯關係之外，用例之間可以有包含關係，比如價格交易和風險分析都要求交易定價，而且表述交易定價涉及到相當分量的文字工作，針對這種情況就可以表述一個獨立的「交易定價」，並在原來的用例中引用它。
有時候一個用例和另一個用例很相似，但是其作用又略大時，可以使用泛化關係，你可以通俗的將其理解爲面向對象中的繼承關係，子用例繼承父用例中的一切。泛化關係不僅適用於用例，也適用於參與者，在實線上加上空心的箭頭就表示泛化關係。
我們還有一個和泛化關係類似的擴展關係，但是它的規則更多一些。可以通過擴展用例向基用例中添加額外的行爲來擴展基用例的功能，這時基用例必須說明一些「擴張點」，而且擴展用例只能在擴張點處增加補充行爲。一個用例可以有多個擴張點，並且一個擴展用例也可以在一個或多個擴張點處擴張。
我們好像忘了一個系統邊界的概念，因爲一個系統中的每一個功能都有它的所屬範圍，劃分系統邊界對於決定系統規模和分配責任是十分重要的，在 UML 中使用矩形框來表達系統的邊界，在其左上方放置系統的名字。
參考內容：用例圖詳解