本章介紹UML建模元素 1：Stereotype-也被稱為類型、構造型 UML里的元素擴展，簡單來說其功能就是在已有的類型上添加一些標記，類似於打個戳，從而生成新的東西。 簡單的說加一句話來更加清楚準確描述這個類。 2：Actor（主角、參與者）-是在系統之外與系統交互的某人或某事物，在建模過程中處 ...
本章介紹UML建模元素
1：Stereotype-也被稱為類型、構造型
UML里的元素擴展，簡單來說其功能就是在已有的類型上添加一些標記，類似於打個戳，從而生成新的東西。
簡單的說加一句話來更加清楚準確描述這個類。
2：Actor（主角、參與者）-是在系統之外與系統交互的某人或某事物，在建模過程中處於核心地位。
參與者和系統之間有一個明確的邊界，參與者只能存在於邊界之外，邊界之內的所有人和事物都不是參與者。
人或物都可以時參與者；
3：如何確定參與者-一定是啟動業務的主角
4：業務主角和業務工人
業務主角（business actor）是參與者的一個版型，用於定義業務的主角，不依賴電腦系統。業務主角是與業務系統有著交互的人和事物，用來確定業務範圍。
業務範圍：項目所涉及的所有客戶業務的客觀存在；系統範圍：軟體將要實現對應業務的系統功能。
業務工人被動參與業務
5：參與者和干係人
干係人-是與要建設的這個系統有利益相關的一切人和事
參與者就是干係人代表，對系統提出要求來獲得他所代表的涉眾的利益。
用戶（user），指的是系統的使用者，是參與者的代表，一個用戶可以代理多個參與者。
角色（role），指的是參與者的職責，一個角色代表了系統中的一類職責。
6:用例：一種把現實世界的需求捕獲下來的方法。用例定義了一組用例實例，其中每個實例都是系統所執行的一系列操作，這些操作生成特定主角可以觀測的值。
一個用例就是與參與者互動，並且給參與者提供可觀測的有意義結果的一系列活動的集合。
一個場景就是一個用例的實例。捕獲功能性需求就是用例的作用
一個完整的用例定義由參與者、前置條件、場景、後置條件構成。如下圖所示
用例的特征：相對獨立的、結果可觀測和有意義。
這件事必須由一個參與者發起。不存在沒有參與者的用例，用例不應該自動啟動，也不應該主動啟動另一個用例。
用例必然是以動賓短語形式出現的
一個用例就是一個需求單元、分析單元、設計單元、開發單元、測試單元，甚至部署單元。
7：用例的粒度-是指的一個用例所描述事件的大小
在業務建模階段，用例的粒度以每個用例能夠說明一件完整的事情為宜，即一個用例可以描述一項完整的業務流程。
在概念建模階段，以每個用例能完整描述事件流為宜；
在系統建模階段，用例視角是針對電腦的，因此用例的粒度以一個用例能夠描述操作者與電腦的一次完整交互為宜。
現實情況中，根據系統的大小選擇不同用例粒度，可以更好適應其需求範圍。
不論粒度如何選擇，必須把握的原則是在同一個需求階段，所有用例的粒度應該是同一個量級的。
8：用例的獲得
用例的來源就是參與者對系統的期望。 一個明確的有效的目標才是一個用力的來源。 一個真實的目標應當完備地表達主角的期望。 一個有效的目標應當在系統邊界內，由主角發動，並具有明確的後果。
9：用例和功能的誤區
用例需要從使用者的觀點出發來描述軟體；功能是脫離使用者的願望而客觀存在的。
用例是系統性的，以開燈為例，需要描述誰在什麼情況下通過什麼方式開燈結果是什麼；
功能是孤立的，只要按下開關燈就亮；
描述一個事物可以從三個方面：
- 這個事物是什麼--強調結構組成，比如車由發動機、剎車系統……組成
- 這個事物能做什麼--強調功能，可以帶人、載物、空調……
- 人們能夠用這個事物做什麼--可以踩油門提高車速，踩剎車減速…
用例可以解釋為一系列完成一個特定目標的功能的組合，針對不同的應用場景，這些功能體現不同的組合方式。
10、目標和步驟的誤區
步驟不能完整反映參與者的目標，不能作為用例；
用例體現的完整的目標，達成目標需要幾個步驟；
當邊界發生變化，步驟也可以變為用例，
11、用例顆粒--在同一需求階段的用例顆粒應該保持在同一量級
