軟件需求工程ppt課件(已修改)
2025-09-23 20:23 本頁面
【正文】 1 理解用例 ? 用例是黑盒？白盒？ ? 用例是 相鄰 系統(tǒng)與系統(tǒng)的交互。 涉眾代表 /用戶 與系統(tǒng)直接交互的對象 其他計算機系統(tǒng) (“參與者 ”) 外部事件 （如：滿足 特定時間） …… 2 1. 抽象層次 是面向?qū)ο蠓椒ㄖ袠O其重要且非常難以把握的技巧； 2. 要想建立好模型，就需學會站在不同的抽象層次考慮問題。 3. 抽象層次越高，被屏蔽（或者說封裝）的信息也就越多，信息量越少也就越容易理解和處理。 抽象層次 3 統(tǒng)一過程一般抽象層次 4 1. 什么時候選擇什么樣的層次以及總共抽象多少層？ 用例粒度 2. 抽象層次與邊界的選擇總是相生相伴邊界 抽象層次相關(guān)的問題 5 1. 一切都是對象； 2. 對象都是獨立的； 3. 對象都具有原子性； 4. 對象都是可抽象的； 5. 對象都有層次性。 對象分析方法 6 2. 參與者（ actor） : ? 定義： actor是在系統(tǒng)之外與系統(tǒng)交互的某人或某事物。如圖所示： UML核心元素 ? 參與者位于邊界之外； ? 參與者可以非人。 7 ? 發(fā)現(xiàn)參與者：參與者的一個重要來源是涉眾，從涉眾中找出那些 直接對系統(tǒng)發(fā)出動作 ，或 直接從系統(tǒng)中接收反饋 的涉眾。在查找參與者的過程中，可以詢問以下問題以幫助確定參與者： ? 誰負責提供、使用或刪除信息？ ? 誰將使用此功能？ ? 誰對某個特定功能感興趣？ ? 在組織中的什么地方使用系統(tǒng)？ ? 誰負責支持和維護系統(tǒng)？ ? 系統(tǒng)有哪些外部資源？ ? 其他還有哪些系統(tǒng)將需要與該系統(tǒng)進行交互？ UML核心元素 8 ? 參與者一定是 直接 并且 主動地 向系統(tǒng)發(fā)出動作并 獲得反饋 的，否則就不是參與者。 UML核心元素 9 ? 業(yè)務主角（ busuness actor）：是參與者的一個構(gòu)造類型，特別用于定義業(yè)務的參與者，在需求階段使用。業(yè)務主角是與業(yè)務系統(tǒng)有著交互的人和事物，他們用來確定業(yè)務范圍。業(yè)務主角的特殊性在于它針對的是業(yè)務人員而非計算機用戶。 ? 業(yè)務工人（ business worker）：處于系統(tǒng)邊界內(nèi)，被動地參與了業(yè)務的執(zhí)行過程。業(yè)務工人不是參與者。 UML核心元素 10 ? 參與者與其他成員的關(guān)系 ? 參與者與涉眾（項目干系人、相關(guān)方）：參與者是涉眾代表， 他們的要求就是系統(tǒng)需求的來源； ? 參與者與用戶（ user）：用戶是系統(tǒng)的使用者。用戶是參與者的代表，或者說是參與者的實例或代理。并非所有的參與者都是用戶。 ? 參與者與角色（ role）：角色是參與者的職責，角色是一個抽象的概念，從眾多參與者的職責中抽象出相同的那一部分，將其命名形成一個角色。一個角色代表了系統(tǒng)的一類職責。由于一個用戶可以代理多個參與者，因此一個用戶可以擁有多個職責，也就是可以被指定多個角色。 UML核心元素 11 ? 參與者、涉眾、和角色的關(guān)系 UML核心元素 12 3. 用例（ Use Case） ? 基本概念：官方文檔對用例是這樣定義的：用例定義了一組用例實例，其中每個實例都是系統(tǒng)所執(zhí)行的一系列操作，這些操作生成特定主角可以觀測的值。 ? 一個完整的用例定義由參與者、前置條件、場景、后置條件構(gòu)成。如圖所示： UML核心元素 13 ? 用例的特征： ? 用例是相對獨立的。 UML核心元素 14 ? 用例的特征： ? 用例的執(zhí)行結(jié)果對參與者來說是可觀測的和有意義的。 UML核心元素
環(huán)評公示相關(guān)推薦
鄂ICP備17016276號-1