《大象 Thinking in UML》學習筆記（三）——UML核心元素之參與者、用例
阿新 • • 發佈：2019-01-27
一、版型在UML裡有一個概念叫版型（stereotype），也被稱為型別、構造型。版型是由UML裡的元素擴充套件而來，每個元模型都有很多版型，比如用例有“業務用例”、“業務用例實現”等版型。當我們需要時候我們也可以根據UML裡的元素自定義版型來輔助建模。二、參與者參與者（actor）是在系統之外與系統互動的某人或某事物，在建模過程中處於核心地位。參與者和系統之間有一個明確的邊界，參與者只能存在於邊界之外，邊界之內的所有人和事物都不是參與者。
每個用例都必須有參與者，參與者可以非人，但一定是啟動業務的主角。三、業務主角和業務工人業務主角（business actor）是參與者的一個版型，用於定義業務的參與者。業務主角是與業務系統有著互動的人和事物，他們用來確定業務範圍。 
業務工人（business worker）是指的系統邊界內，被動參與了業務的執行過程的人。四、參與者相關關係涉眾（stakeholder），也稱為干係人，是與要建設的這個系統有利益相關的一切人和事。參與者就是涉眾代表，對系統提出要求來獲得他所代表的涉眾的利益。使用者（user），指的是系統的使用者，是參與者的代表，一個使用者可以代理多個參與者。 
五、用例用例的基本概念用例（Use case）是一種把現實世界的需求捕獲下來的方法。用例定義了一組用例例項，其中每個例項都是系統所執行的一系列操作，這些操作生成特定主角可以觀測的值。在UML裡，除了用例之外，所有其他元素都是封裝獨立的。用例推動這些UML元素關聯起來，從而實現某個功能。所以說用例是UML建模中最重要的一個元素。一個完整的用例定義由參與者、前置條件、場景、後置條件構成。如下圖所示：
一個系統的功能性是有一些對系統有願望的參與者要做的一些事情構成的，事情完成後就達成了參與者的一個願望，當全部參與者的所有願望都能夠通過用例來達到，那麼這個系統就被確定下來了。 
這件事必須由一個參與者發起。不存在沒有參與者的用例，用例不應該自動啟動，也不應該主動啟動另一個用例。
用例必然是以動賓短語形式出現的。
一個用例就是一個需求單元、分析單元、設計單元、開發單元、測試單元，甚至部署單元。
用例的粒度用例的粒度是指的一個用例所描述事件的大小。在業務建模階段，用例的粒度以每個用例能夠說明一件完整的事情為宜，即一個用例可以描述一項完整的業務流程。在系統建模階段，用例視角是針對計算機的，因此用例的粒度以一個用例能夠描述操作者與計算機的一次完整互動為宜。現實情況中，根據系統的大小選擇不同用例粒度，可以更好適應其需求範圍。不論粒度如何選擇，必須把握的原則是在同一個需求階段，所有用例的粒度應該是同一個量級的。用例的獲得用例的來源就是參與者對系統的期望。一個明確的有效的目標才是一個用力的來源。一個真實的目標應當完備地表達主角的期望。一個有效的目標應當在系統邊界內，由主角發動，並具有明確的後果。六、用例相關的誤區用例和功能的誤區用例需要從使用者的觀點出發來描述軟體；功能是脫離使用者的願望而客觀存在的。用例是系統性的，以開燈為例，需要描述誰在什麼情況下通過什麼方式開燈結果是什麼；功能是孤立的，只要按下開關燈就亮。用例可以解釋為一系列完成一個特定目標的功能的組合，針對不同的應用場景，這些功能體現不同的組合方式。目標和步驟的誤區一個用例是參與者對目標系統的一個願望，一個完整的事件，為了完成這個事件需要經由很多步驟，但這些步驟不能夠完整地反映參與者的目標，不能夠作為用例。用例粒度的誤區用例的粒度不是越小越好，太小了會使建模無比繁瑣且沒意義；一個系統裡用例粒度如果不一，會使系統邊界不確定，從而系統結構混亂。七、業務用例和業務用例實現業務用例（business use case）是用例版型中的一種，專門用於需求階段的業務建模。
業務模型是針對客戶業務的模型，與計算機系統建模無關，只是業務領域的一個模型。業務用例的參與者是業務主角，如果說用例是用來獲取功能性需求，那麼業務用例用來獲取功能性業務。業務用例實現（business use case realization）是用例版型中的一種，專門用於需求階段的業務建模。
業務用例實現是業務用例的一種實現方式，表達了同一項業務的不同實現方式。業務用例和業務用例實現的關係舉例如圖
每個用例都必須有參與者，參與者可以非人，但一定是啟動業務的主角。三、業務主角和業務工人業務主角（business actor）是參與者的一個版型，用於定義業務的參與者。業務主角是與業務系統有著互動的人和事物，他們用來確定業務範圍。
業務工人（business worker）是指的系統邊界內，被動參與了業務的執行過程的人。四、參與者相關關係涉眾（stakeholder），也稱為干係人，是與要建設的這個系統有利益相關的一切人和事。參與者就是涉眾代表，對系統提出要求來獲得他所代表的涉眾的利益。使用者（user），指的是系統的使用者，是參與者的代表，一個使用者可以代理多個參與者。
五、用例用例的基本概念用例（Use case）是一種把現實世界的需求捕獲下來的方法。用例定義了一組用例例項，其中每個例項都是系統所執行的一系列操作，這些操作生成特定主角可以觀測的值。在UML裡，除了用例之外，所有其他元素都是封裝獨立的。用例推動這些UML元素關聯起來，從而實現某個功能。所以說用例是UML建模中最重要的一個元素。一個完整的用例定義由參與者、前置條件、場景、後置條件構成。如下圖所示：
一個系統的功能性是有一些對系統有願望的參與者要做的一些事情構成的，事情完成後就達成了參與者的一個願望，當全部參與者的所有願望都能夠通過用例來達到，那麼這個系統就被確定下來了。
這件事必須由一個參與者發起。不存在沒有參與者的用例，用例不應該自動啟動，也不應該主動啟動另一個用例。
用例必然是以動賓短語形式出現的。
一個用例就是一個需求單元、分析單元、設計單元、開發單元、測試單元，甚至部署單元。
用例的粒度用例的粒度是指的一個用例所描述事件的大小。在業務建模階段，用例的粒度以每個用例能夠說明一件完整的事情為宜，即一個用例可以描述一項完整的業務流程。在系統建模階段，用例視角是針對計算機的，因此用例的粒度以一個用例能夠描述操作者與計算機的一次完整互動為宜。現實情況中，根據系統的大小選擇不同用例粒度，可以更好適應其需求範圍。不論粒度如何選擇，必須把握的原則是在同一個需求階段，所有用例的粒度應該是同一個量級的。用例的獲得用例的來源就是參與者對系統的期望。一個明確的有效的目標才是一個用力的來源。一個真實的目標應當完備地表達主角的期望。一個有效的目標應當在系統邊界內，由主角發動，並具有明確的後果。六、用例相關的誤區用例和功能的誤區用例需要從使用者的觀點出發來描述軟體；功能是脫離使用者的願望而客觀存在的。用例是系統性的，以開燈為例，需要描述誰在什麼情況下通過什麼方式開燈結果是什麼；功能是孤立的，只要按下開關燈就亮。用例可以解釋為一系列完成一個特定目標的功能的組合，針對不同的應用場景，這些功能體現不同的組合方式。目標和步驟的誤區一個用例是參與者對目標系統的一個願望，一個完整的事件，為了完成這個事件需要經由很多步驟，但這些步驟不能夠完整地反映參與者的目標，不能夠作為用例。用例粒度的誤區用例的粒度不是越小越好，太小了會使建模無比繁瑣且沒意義；一個系統裡用例粒度如果不一，會使系統邊界不確定，從而系統結構混亂。七、業務用例和業務用例實現業務用例（business use case）是用例版型中的一種，專門用於需求階段的業務建模。
業務模型是針對客戶業務的模型，與計算機系統建模無關，只是業務領域的一個模型。業務用例的參與者是業務主角，如果說用例是用來獲取功能性需求，那麼業務用例用來獲取功能性業務。業務用例實現（business use case realization）是用例版型中的一種，專門用於需求階段的業務建模。
業務用例實現是業務用例的一種實現方式，表達了同一項業務的不同實現方式。業務用例和業務用例實現的關係舉例如圖