一、stereotype(類型、構(gòu)造型)
??這個概念是對一個UML元素基礎(chǔ)定義的擴展,在同一個元素基礎(chǔ)定義的基礎(chǔ)上賦予特別的含義,使得這個元素適用于特定的場合萌庆。
二、參與者
??參與者:在系統(tǒng)之外與系統(tǒng)交互的某人或某事物瓢剿。由定義可知參與者包含以下兩個特點:
1)參與者位于邊界之外额划;
??系統(tǒng)之外的定義說明在參與者和系統(tǒng)之間有一個明確的邊界,參與者只可能在邊界之外疾党。要弄明白誰是參與者首先要鬧明白系統(tǒng)的邊界音诫。可通過以下問題來確定系統(tǒng)的邊界:誰對系統(tǒng)有著明確的目標(biāo)和要求并且主動發(fā)出動作雪位?系統(tǒng)是為誰服務(wù)的竭钝?
2)參與者可以非人。
??例如每天自動統(tǒng)計網(wǎng)頁訪問量雹洗,生成統(tǒng)計報表香罐,并發(fā)送至管理員信箱。這個需求的參與者是誰时肿?功能性需求的用例有個特征是“不存在沒有參與者的用例庇茫,用例不應(yīng)該自動啟動,也不應(yīng)該主動啟動另一個用例”螃成。任何一個需求都有啟動者旦签,如果找不到啟動者,那么它就不是一個功能性需求寸宏。例如:客戶提出要建立的系統(tǒng)界面很友好宁炫,在每個頁面上都有操作提示。這個要求就找不到啟動者氮凝,他就不是一個功能性需求羔巢,實際上他是系統(tǒng)可用性的一個具體要求≌终螅回到開頭的問題朵纷,這個需求的參與者就是一個計時器,它每天在某個固定的時刻啟動這個需求永脓。
??業(yè)務(wù)主角是參與者的一個版型,特別用于定義業(yè)務(wù)的參與者常摧,在需求階段使用搅吁。其特殊性在于威创,它針對的是業(yè)務(wù)人員而不是計算機用戶。
??業(yè)務(wù)工人:被動參與業(yè)務(wù)谎懦,不需要建立業(yè)務(wù)模型肚豺,常見于領(lǐng)域模型和用例場景。最直接區(qū)分參與者和業(yè)務(wù)工人的方法是判斷在邊界之外還是邊界之內(nèi)界拦。以下三個問題可用來區(qū)分業(yè)務(wù)工人:1)他是主動向系統(tǒng)發(fā)出動作的嗎吸申?2)他有完整的業(yè)務(wù)目標(biāo)嗎?3)系統(tǒng)是為他服務(wù)的嗎享甸?
三截碴、用例
作用:用例用于捕捉功能性需求。
定義:一個用例就是與參與者交互的蛉威,并且給參與者提供可觀測的有意義的結(jié)果的一系列活動的集合日丹。
特征:1)用例是相對獨立的。即它不需要與其他用例交互而獨自完成參與者的目的蚯嫌。用例本質(zhì)提現(xiàn)了參與者的愿望哲虾,不能完整達(dá)到參與者愿望的不能稱為用例。例如取錢是一個有效的用例择示,填寫取款單卻不是束凑。
2)用例的執(zhí)行結(jié)果對參與者來說是可觀測的和有意義的。比如有個后臺進程監(jiān)控參與者在系統(tǒng)里的操作栅盲。雖然他是系統(tǒng)的一個必須的組成部分湘今,但它在需求階段卻不應(yīng)該作為用例出現(xiàn)。因為這是一個后臺進程剪菱,對參與者來說是不可觀測的摩瞎,他應(yīng)作為系統(tǒng)需求在補充規(guī)約中定義而不是一個用戶需求。
3)用例必須由參與者發(fā)起孝常,不存在沒有參與者的用例旗们。用例不該自動啟動,也不該主動啟動另一個用例构灸。
4)用例必然是以動賓短語形式出現(xiàn)上渴。
5)一個用例就是一個需求單元、分析單元喜颁、設(shè)計單元稠氮、開發(fā)單元、測試單元半开、甚至部署單元隔披。
粒度:項目階段不同,使用不同的粒度寂拆。
??在業(yè)務(wù)建模階段奢米,用例的粒度以每個用例能說明一件完整的事情為宜抓韩,即一個用例可以描述一項完整的業(yè)務(wù)流程。這將有助于明確需求范圍鬓长。
??在用例分析階段谒拴,即概念建模階段,用例的粒度以每個用例能描述一個完整的事件流為宜涉波∮⑸希可理解為一個用例描述一項完整業(yè)務(wù)中的一個步驟。此階段需要采用一些面向?qū)ο蟮姆椒ㄆ「玻瑲w納和抽象出業(yè)務(wù)用例中的關(guān)鍵概念模型并為之建模苍日。
??在系統(tǒng)建模階段,用例視角是針對計算機的城侧,因此用例的粒度以一個用例能描述操作者與計算機的一次完整交互為宜易遣。
不論粒度如何選擇彼妻,必須把握的原則是在同一個需求階段嫌佑,所有用例的粒度應(yīng)該是同一個量級。