UML之2、建模元素(1)

本章介紹UML建模元素測試

1:Stereotype-也被稱爲類型、構造型spa

UML裏的元素擴展,簡單來講其功能就是在已有的類型上添加一些標記,相似於打個戳,從而生成新的東西。設計

簡單的說加一句話來更加清楚準確描述這個類。3d

2:Actor(主角、參與者)-是在系統以外與系統交互的某人或某事物,在建模過程當中處於核心地位。代理

參與者和系統之間有一個明確的邊界,參與者只能存在於邊界以外,邊界以內的全部人和事物都不是參與者。blog

人或物均可以時參與者;事件

 

3:如何肯定參與者-必定是啓動業務的主角開發

 4:業務主角和業務工人部署

業務主角(business actor)是參與者的一個版型,用於定義業務的主角,不依賴計算機系統。業務主角是與業務系統有着交互的人和事物,用來肯定業務範圍。擴展

業務範圍:項目所涉及的全部客戶業務的客觀存在;系統範圍:軟件將要實現對應業務的系統功能。

業務工人被動參與業務

 5:參與者和干係人

干係人-是與要建設的這個系統有利益相關的一切人和事

參與者就是干係人表明,對系統提出要求來得到他所表明的涉衆的利益。

用戶(user),指的是系統的使用者,是參與者的表明,一個用戶能夠代理多個參與者。 

角色(role),指的是參與者的職責,一個角色表明了系統中的一類職責。

 

 

 6:用例:一種把現實世界的需求捕獲下來的方法。用例定義了一組用例實例,其中每一個實例都是系統所執行的一系列操做,這些操做生成特定主角能夠觀測的值。

一個用例就是與參與者互動,而且給參與者提供可觀測的有意義結果的一系列活動的集合。

一個場景就是一個用例的實例。捕獲功能性需求就是用例的做用

一個完整的用例定義由參與者、前置條件、場景、後置條件構成。以下圖所示

 

 

 用例的特徵:相對獨立的、結果可觀測和有意義。

這件事必須由一個參與者發起。不存在沒有參與者的用例,用例不該該自動啓動,也不該該主動啓動另外一個用例。

 

用例必然是以動賓短語形式出現的

 

一個用例就是一個需求單元、分析單元、設計單元、開發單元、測試單元,甚至部署單元。

 7:用例的粒度-是指的一個用例所描述事件的大小

在業務建模階段,用例的粒度以每一個用例可以說明一件完整的事情爲宜,即一個用例能夠描述一項完整的業務流程。

在概念建模階段,以每一個用例能完整描述事件流爲宜;

在系統建模階段,用例視角是針對計算機的,所以用例的粒度以一個用例可以描述操做者與計算機的一次完整交互爲宜。

現實狀況中,根據系統的大小選擇不一樣用例粒度,能夠更好適應其需求範圍。

不論粒度如何選擇,必須把握的原則是在同一個需求階段,全部用例的粒度應該是同一個量級的。

 8:用例的得到

用例的來源就是參與者對系統的指望。
 一個明確的有效的目標纔是一個用力的來源。
 一個真實的目標應當完備地表達主角的指望。
 一個有效的目標應當在系統邊界內,由主角發動,並具備明確的後果。

9:用例和功能的誤區

 用例須要從使用者的觀點出發來描述軟件;功能是脫離使用者的願望而客觀存在的。

用例是系統性的,以開燈爲例,須要描述誰在什麼狀況下經過什麼方式開燈結果是什麼;

功能是孤立的,只要按下開關燈就亮;

描述一個事物能夠從三個方面:

  • 這個事物是什麼--強調結構組成,好比車由發動機、剎車系統……組成
  • 這個事物能作什麼--強調功能,能夠帶人、載物、空調……
  • 人可以用這個事物作什麼--能夠踩油門提升車速,踩剎車減速…

用例能夠解釋爲一系列完成一個特定目標的功能的組合,針對不一樣的應用場景,這些功能體現不一樣的組合方式。

 十、目標和步驟的誤區

相關文章
相關標籤/搜索