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