UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)課件

UML系統(tǒng)需求分析建模實(shí)例（包括業(yè)務(wù)建模）UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)原始需求某公司鑒于業(yè)務(wù)和員工的快速發(fā)展，為了提升整體工作效率，公司準(zhǔn)備開發(fā)一套員工報(bào)賬系統(tǒng)，取代原來的人工處理方式，更加方便的服務(wù)于員工日常的賬務(wù)操作。財(cái)務(wù)部門能夠通過賬務(wù)系統(tǒng)定期向各部門負(fù)責(zé)人反映賬務(wù)統(tǒng)計(jì)情況，并設(shè)置和維護(hù)相關(guān)額度準(zhǔn)則。系統(tǒng)應(yīng)該具有基于先進(jìn)技術(shù)的操作界面。UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)原始需求

愿景1.為員工提供賬務(wù)的自動(dòng)化辦理，提高辦事效率，方便員工。2.方便財(cái)務(wù)部門管理好賬務(wù)信息。UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)涉眾分析涉眾解釋期望員工公司的正式錄用雇員通過網(wǎng)上辦理賬務(wù)業(yè)務(wù)申請，計(jì)算機(jī)控制流程部門經(jīng)理部門負(fù)責(zé)人，負(fù)責(zé)審核員工提交的申請方便審核操作，通過計(jì)算機(jī)代替原來的手工審核方式。公司主任公司負(fù)責(zé)人，負(fù)責(zé)2次審核員工提交的申請方便審核操作，通過計(jì)算機(jī)代替原來的手工審核方式，界面友好易用。財(cái)務(wù)主任公司財(cái)務(wù)部門負(fù)責(zé)人，負(fù)責(zé)發(fā)放報(bào)賬款項(xiàng)通過計(jì)算機(jī)轉(zhuǎn)賬的方式替代原來的人為付款方式。UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)業(yè)務(wù)用例獲取（1）定義："業(yè)務(wù)用例從一個(gè)外部的，增加值的角度來描述一個(gè)業(yè)務(wù)過程。為了給這個(gè)業(yè)務(wù)的涉眾創(chuàng)造價(jià)值，業(yè)務(wù)用例是超越組織邊界的業(yè)務(wù)過程，很可能包括合作伙伴和供應(yīng)商。“"業(yè)務(wù)用例：業(yè)務(wù)過程是描述這個(gè)業(yè)務(wù)的具體工作流的；一次涉眾與實(shí)現(xiàn)業(yè)務(wù)目標(biāo)的業(yè)務(wù)之間的交互。它可能包含手工和自動(dòng)化的過程，也可能發(fā)生在一個(gè)長期的時(shí)間段中?！癠ML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)業(yè)務(wù)用例VS系統(tǒng)用例UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)面向?qū)ο蠓治雠c設(shè)計(jì)業(yè)務(wù)用例系統(tǒng)用例分析模型UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)業(yè)務(wù)用例獲取（2）要獲取用例就必須先得出邊界，邊界有了，那么邊界外的業(yè)務(wù)主角就有了，那么業(yè)務(wù)主角對這個(gè)邊界內(nèi)的目標(biāo)就是用例。UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)業(yè)務(wù)用例獲取（3）以每個(gè)業(yè)務(wù)目標(biāo)為一個(gè)邊界，明確了哪些涉眾與這一業(yè)務(wù)目標(biāo)有關(guān)，他們作為業(yè)務(wù)主角站在這一邊界外提出他們的期望，這些期望作為用例都是為實(shí)現(xiàn)這一業(yè)務(wù)目標(biāo)服務(wù)的（不符合這一業(yè)務(wù)目標(biāo)的期望則不被采納）。UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)業(yè)務(wù)用例獲?。?）獲取方法資料、問卷、訪談、觀察、調(diào)研競爭對手訪談實(shí)例：以員工賬務(wù)服務(wù)邊界為例，根據(jù)涉眾分析報(bào)告和客戶訪談得出的。假定員工對這個(gè)系統(tǒng)的期望和目標(biāo)有通過計(jì)算機(jī)申請報(bào)銷業(yè)務(wù)，申請借款業(yè)務(wù)，這兩個(gè)期望都是與員工賬務(wù)服務(wù)這個(gè)特定的業(yè)務(wù)目標(biāo)有關(guān)的，所以可以作為業(yè)務(wù)用例被納入到員工賬務(wù)服務(wù)邊界之中。如果假設(shè)員工也可以參與管理賬務(wù)信息，那么得出的員工對系統(tǒng)的期望就不止這兩個(gè)，但是分析的時(shí)候要注意與員工賬務(wù)服務(wù)這一業(yè)務(wù)目標(biāo)相關(guān)的期望只有申請報(bào)銷業(yè)務(wù)和申請借款業(yè)務(wù)兩個(gè)，其他的期望是與管理賬務(wù)信息這個(gè)業(yè)務(wù)目標(biāo)有關(guān)，應(yīng)當(dāng)被劃分到管理賬務(wù)信息邊界中去。UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)一個(gè)疑問的解答貌似部門經(jīng)理也有對員工賬務(wù)服務(wù)邊界有貢獻(xiàn)啊，不是有參與審核嗎，為啥部門經(jīng)理審核賬單就不能算一個(gè)業(yè)務(wù)用例呢？之所以會(huì)出現(xiàn)這個(gè)疑惑和誤區(qū)還是因?yàn)闆]有分清楚邊界造成的。因?yàn)閷τ趩T工賬務(wù)服務(wù)邊界來說，處于該邊界的之外的業(yè)務(wù)主角只有員工，而部門經(jīng)理，公司主任，財(cái)務(wù)主任都是在這個(gè)邊界之內(nèi)的，他們的工作都只是完成業(yè)務(wù)主角提出的業(yè)務(wù)用例的一個(gè)步驟，在這里他們作為業(yè)務(wù)工人無權(quán)提出業(yè)務(wù)用例，他們的職責(zé)可以在繪制用例場景活動(dòng)圖的時(shí)候通過泳道體現(xiàn)出來。UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)業(yè)務(wù)建模業(yè)務(wù)用例圖業(yè)務(wù)用例實(shí)現(xiàn)場景【活動(dòng)圖或者時(shí)序圖】業(yè)務(wù)規(guī)則業(yè)務(wù)用例規(guī)約UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)業(yè)務(wù)用例實(shí)現(xiàn)場景報(bào)銷申請的業(yè)務(wù)用例場景活動(dòng)圖UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)系統(tǒng)需求建模系統(tǒng)用例圖系統(tǒng)用例規(guī)約UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)方法：業(yè)務(wù)用例到系統(tǒng)用例的向下流動(dòng)UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)系統(tǒng)用例確定映射直接將業(yè)務(wù)用例實(shí)現(xiàn)場景中的某個(gè)具體過程轉(zhuǎn)換為系統(tǒng)用例抽象當(dāng)業(yè)務(wù)場景中的備選用例不能直接被映射時(shí)，抽象得到。合并拆分演繹業(yè)務(wù)用例實(shí)現(xiàn)場景中沒有這個(gè)用例，但是系統(tǒng)需要。UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)額外例子－用電申請業(yè)務(wù)用例場景UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)額外例子－用電申請業(yè)務(wù)用例場景UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)找用例（１）引入計(jì)算機(jī)，降低用例粒度，進(jìn)入系統(tǒng)模型的建立過程。系統(tǒng)用例可以從業(yè)務(wù)用例場景中推導(dǎo)出來，業(yè)務(wù)用例場景一般描述為某某做什么，某某做什么，這個(gè)某某做什么就是一個(gè)備選的系統(tǒng)用例，然后從備選用例中確定系統(tǒng)用例，分析過程如下：員工申請報(bào)銷，這是一個(gè)填寫報(bào)賬單的過程，是通過計(jì)算機(jī)完成的，可以直接映射成一個(gè)系統(tǒng)用例；部門經(jīng)理審核報(bào)賬單，這是通過計(jì)算機(jī)來操作決定是否通過審核，可以直接映射成一個(gè)系統(tǒng)用例；UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)找用例（２）部門經(jīng)理說明（填寫）拒絕原因，經(jīng)過分析，這個(gè)備選用例其實(shí)是審核報(bào)賬單的結(jié)果之一，也就是說審核報(bào)賬單中包含了說明拒絕原因這個(gè)行為，所以取消部門經(jīng)理說明（填寫）拒絕原因的獨(dú)立用例資格，將它作為部門經(jīng)理審核報(bào)賬單的包含用例。公司主任審核報(bào)賬單，公司主任說明（填寫）拒絕原因同上。財(cái)務(wù)主任發(fā)放還款，這個(gè)備選用例是否能成為系統(tǒng)用例要看情況的，如果財(cái)務(wù)主任是人為的發(fā)放現(xiàn)金或者人為的去銀行匯款轉(zhuǎn)賬，那么沒有通過計(jì)算機(jī)（意思是該系統(tǒng)）進(jìn)行操作，就不能算是一個(gè)系統(tǒng)用例；而如果財(cái)務(wù)主任是通過系統(tǒng)提供的轉(zhuǎn)賬功能匯款的話，那么就是一個(gè)系統(tǒng)用例?；仡櫳姹姺治鰣?bào)告后我們確定這可以成為一個(gè)系統(tǒng)用例。UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)完成系統(tǒng)用例圖UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)系統(tǒng)用例場景－描述人機(jī)交互過程申請報(bào)銷UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)撰寫用例規(guī)約和規(guī)則用例圖只是表達(dá)了用例的目標(biāo)，這是遠(yuǎn)遠(yuǎn)不夠的。用例的背后封裝了不同級(jí)別的相關(guān)需求，我們需要通過書寫用例規(guī)約把這些需求表達(dá)出來。用例規(guī)約就是以用例方式組織的需求規(guī)約。UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)用例規(guī)約模板（１）UML系統(tǒng)需求分析建模實(shí)例(包括業(yè)務(wù)建模)后記Ｉ－系統(tǒng)分析員工報(bào)銷申請用例實(shí)現(xiàn)的分析類時(shí)序圖UML系