UML系統(tǒng)需求分析建模實例包括業(yè)務建模PPT學習教案

1、會計學1UML系統(tǒng)需求分析建模實例包括業(yè)務建系統(tǒng)需求分析建模實例包括業(yè)務建模模第1頁/共28頁第2頁/共28頁涉眾涉眾解釋解釋期望期望員工公司的正式錄用雇員通過網(wǎng)上辦理賬務業(yè)務申請，計算機控制流程部門經(jīng)理部門負責人，負責審核員工提交的申請方便審核操作，通過計算機代替原來的手工審核方式。公司主任公司負責人，負責 2 次審核員工提交的申請方便審核操作，通過計算機代替原來的手工審核方式，界面友好易用。財務主任公司財務部門負責人，負責發(fā)放報賬款項通過計算機轉(zhuǎn)賬的方式替代原來的人為付款方式。第3頁/共28頁第4頁/共28頁業(yè)務用例模型業(yè)務用例模型系統(tǒng)用例模型系統(tǒng)用例模型不同之處范圍業(yè)務用例著重于業(yè)務操作

2、。它們表示實現(xiàn)業(yè)務目標的業(yè)務中的具體工作流。業(yè)務過程可能涉及手工和自動過程，并且在一段長期的時間內(nèi)進行。系統(tǒng)用例著重于要設計的軟件系統(tǒng)。參與者如何與軟件系統(tǒng)進行交互？我們在系統(tǒng)用例說明中書寫的事件流應該足夠詳細，從而用作編寫系統(tǒng)測試腳本的出發(fā)點。白盒與黑盒業(yè)務用例常常是以白盒形式編寫的。它們描述了被建模的組織中的人和部門之間的交互。我們使用業(yè)務用例來說明在“現(xiàn)有”業(yè)務模型中組織如何工作。然后我們重構(gòu)“現(xiàn)有”的業(yè)務用例模型，讓其面向?qū)⒁５慕M織的未來設計。我們需要創(chuàng)建什么新角色和部門來提供更多價值，或者消除業(yè)務問題？什么角色和部門需要消失？系統(tǒng)用例幾乎總是以黑盒形式編寫的。它們描述了軟件系統(tǒng)之

3、外的參與者如何與將被設計的系統(tǒng)進行交互。系統(tǒng)用例詳細闡明了系統(tǒng)需求。系統(tǒng)用例模型的目的是從涉眾的角度說明需求，而不是設計如何滿足需求。涉眾業(yè)務用例圖中，可以讓業(yè)務參與者【業(yè)務執(zhí)行者】和業(yè)務角色【業(yè)務工人】與業(yè)務用例進行交互。在系統(tǒng)用例圖中，讓參與者與用例進行交互。相同之處兩者都有參與者。在業(yè)務用例圖中，將一個參與者原型化為 。兩者都有用例。在業(yè)務用例模型中，將一個用例原型化為 。在參與者與用例之間兩者都有一個通信關(guān)聯(lián)。業(yè)務用例和系統(tǒng)用例都能夠包含、擴展，以及一般化關(guān)聯(lián)。第5頁/共28頁業(yè)務用例系統(tǒng)用例分析模型第6頁/共28頁第7頁/共28頁第8頁/共28頁第9頁/共28頁第10頁/共28頁因為

4、對于員工賬務服務邊界來說，處于該邊界的之外的業(yè)務主角只有員工，而部門經(jīng)理，公司主任，財務主任都是在這個邊界 之內(nèi)的，他們的工作都只是完成業(yè)務主角提出的業(yè)務用例的一個步驟，在這里他們作為業(yè)務工人無權(quán)提出業(yè)務用例，他們的職責可以在繪制用例場景活動圖的時候通 過泳道體現(xiàn)出來。第11頁/共28頁第12頁/共28頁第13頁/共28頁第14頁/共28頁第15頁/共28頁第16頁/共28頁第17頁/共28頁第18頁/共28頁第19頁/共28頁第20頁/共28頁第21頁/共28頁申請報銷第22頁/共28頁第23頁/共28頁用例用例#用例名應是一個動詞短語，應讓讀者一目了然地從名字中就可以知道該用例的目標。使用

5、語境使用語境用例目標，是一個較長的描述，甚至包括觸發(fā)條件。范圍范圍用例的設計范圍，在設計時將系統(tǒng)作為一個黑盒來考慮。級別級別概要、用戶目標、子功能三者之一。主執(zhí)行者主執(zhí)行者也就是該用例的主Actor，在此應列出其名稱，并簡要描述。項目相關(guān)人員項目相關(guān)人員利益利益項目相關(guān)人員項目相關(guān)人員利益利益項目相關(guān)人員名稱項目相關(guān)人員取得的利益前置條件前置條件也就是激發(fā)該用例，所應該滿足的條件。后置條件后置條件也就是該用例完成之后，將執(zhí)行什么動作。成功保證成功保證描述當目標完成后，環(huán)境的變化情況。觸發(fā)事件觸發(fā)事件什么引發(fā)用例，例如時間事件。描述描述步驟步驟活動活動1在這里寫出觸發(fā)事件到目標完成以及清除的步驟。23擴展擴展步驟步驟分支動作分支動