繪制用例ppt課件-wenkub.com
2025-05-01 12:02 本頁面
【正文】 ?完成一個完整的事件需要經(jīng)由很多步驟，但這些步驟不能夠完整的反映參與者的目標(biāo)，不能夠作為用例。 ?功能性觀點和結(jié)構(gòu)性觀點，則可以通過使用者觀點推導(dǎo)出來。 EBP的指導(dǎo)原則只在對應(yīng)用進(jìn)行需求分析時用來尋找主要用例，也即命名、寫出主要用例。 用例的目標(biāo)和范圍 ?發(fā)現(xiàn)用例 ——確定用例的目標(biāo)和范圍 ?用例應(yīng)該在什么 級別和范圍 上表述呢？ 怎樣發(fā)現(xiàn)用例？ ?談判一個供貨合同 ?處理返回值 ?登錄 ?在游戲板上移動棋子 是否是有效的用例 ? ?可以認(rèn)為這些都是用例，但它們處于不同的級別，依賴于系統(tǒng)邊界、參與者和目標(biāo)。 ? 一個參與者并不時指一個特定的人或一個特定的實體 某個參與者可被認(rèn)為是一個有形的、與系統(tǒng)交互的、扮演某種角色的外部實體 張三 李四 注意： 顧客 角色 為什么要定義參與者？ ?某個特定參與者初始化某個用例的原因幾乎總是為什么需要該用例的主要原因 ?參與者在環(huán)境中的角色和其獨一無二的行為及其系統(tǒng)職責(zé)會對用例產(chǎn)生重要的影響 個體客戶 商業(yè)客戶 ？ ?為什么不先找用例？ 先找參與者的原因 ?參與者比用例明顯 ?參與者的個數(shù)遠(yuǎn)比用例的個數(shù)少 ?找到一個參與者，就可以找到一堆用例 ?參與者是系統(tǒng)外部人物的代表，所以是先找出參與者，才能夠從參與者的角度去尋找用例。 《 系統(tǒng)分析師 UML用例實戰(zhàn) 》 的案例基于Wesley和 Richard兩個角色敘述，從兩人開始接到一個書店系統(tǒng)的項目，到動手建立用例模型，并且應(yīng)用用例技術(shù)來估算工時，系統(tǒng)記述了UML用例的應(yīng)用方法。 第 1章 繪制用例圖 《 系統(tǒng)分析師 UML用例實戰(zhàn) 》 理解需求 ?什么是需求？ ? 系統(tǒng)必須提供的能力和必須遵從的條件 ?需求工作的最根本 挑戰(zhàn) 在于：如何去發(fā)現(xiàn)、交流并記?。从涗洠┦裁词钦嬲枰?，并能夠清楚地向用戶和開發(fā)團(tuán)隊的成員講解 ——這個過程的最大難題是如何使得需求的定義沒有二義性 理解需求（續(xù)） ?需求管理 推崇 用“一種條理化的方法尋找、記錄、組織和跟蹤系統(tǒng) 不斷變化 的需求” 影響軟件項目的因素 其它50% 其它50% 不充分的用戶輸入13% 不完整需求 12% 變更需求 12% 技術(shù)技能不足 7% 員工不足 6% 用例到底用在哪？ What How Do 用例圖 用例描述 “用例”先睹為快 ——用例圖 記錄預(yù)約 取消預(yù)約 顯示預(yù)約 接待員
教學(xué)課件相關(guān)推薦
鄂ICP備17016276號-1