需求分析用例圖

需求分析用例圖第1頁，課件共84頁，創(chuàng)作于2023年2月-2-課程內(nèi)容UML概述理解需求需求，難在何處？以用例為中心組織需求基于用例的需求分析過程第2頁，課件共84頁，創(chuàng)作于2023年2月-3-課程內(nèi)容UML概述理解需求需求，難在何處？以用例為中心組織需求基于用例的需求分析過程第3頁，課件共84頁，創(chuàng)作于2023年2月-4-WhatIstheUML?TheUMLisalanguageforVisualizingSpecifyingConstructingDocumentingtheartifactsofasoftware-intensivesystemUnifiedModelingLanguage（統(tǒng)一建模語言）是對象管理組織（OMG）制定的一個通用的、可視化的建模語言標準，可以用來可視化（visualize）、描述（specify）、構造（construct）和文檔化（document）軟件密集型系統(tǒng)的各種工件（artifacts，又譯制品）第4頁，課件共84頁，創(chuàng)作于2023年2月-5-UML誕生工業(yè)化標準化統(tǒng)一化分散的各部分公眾反饋1997.11.17

UML1.1被OMG接納為標準OOPSLA95UnifiedMethod0.8

Booch93OMT-21996.6和1996.10UML0.9&0.911997.9公布UML1.1

1997.1公布UML1.0合作伙伴意見

Booch91OMT-1其他方法

OOSEGradyBoochJimRumbaughIvarJacobson第5頁，課件共84頁，創(chuàng)作于2023年2月-6-UML發(fā)展現(xiàn)狀目前通用的是UML1.x版主要UML1.3、UML1.42003年3月正式發(fā)布UML1.5UML2.02003年6月OMG采納了UML2.0的Superstructure的提案正式文本尚未發(fā)布…第6頁，課件共84頁，創(chuàng)作于2023年2月-7-UML9種圖類圖：類以及類之間的相互關系對象圖：對象以及對象之間相互關系構件圖：構件及其相互依賴關系部署圖：構件在各節(jié)點上的部署順序圖：強調(diào)時間順序的交互圖協(xié)作圖：強調(diào)對象協(xié)作的交互圖狀態(tài)圖：類所經(jīng)歷的各種狀態(tài)活動圖：對工作流建模用例圖：需求捕獲，測試依據(jù)結構行為用例圖靜態(tài)圖實現(xiàn)圖交互圖行為圖第7頁，課件共84頁，創(chuàng)作于2023年2月-8-UML建模工具IBMRationalRose2003BorlandTogether7.0MicrosoftVisio2003SybasePowerDesigner10NetBeansUML……“非程序員雜志”第26到30期UML工具一覽，列出了約129個UML開發(fā)工具第8頁，課件共84頁，創(chuàng)作于2023年2月-9-內(nèi)容安排UML概述理解需求需求，難在何處？以用例為中心組織需求基于用例的需求分析過程第9頁，課件共84頁，創(chuàng)作于2023年2月認識問題分析問題解決問題最終用戶(提出問題)開發(fā)團隊(解決問題)以用戶的身份站在用戶的角度認識問題

獲取需求—用例建模技術以開發(fā)者的身份站在用戶的角度分析問題

分析需求—用例分析技術以開發(fā)者的身份站在開發(fā)團隊的角度分析問題

解決需求—面向?qū)ο笤O計第10頁，課件共84頁，創(chuàng)作于2023年2月-11-需求—建造“正確”的系統(tǒng)需求：系統(tǒng)必須滿足的條件或具備的能力軟件質(zhì)量準則“FURPS”功能性（Functionality）可用性（Usability）可靠性（Reliability）性能（Performance）可支持性（Supportability）非功能性需求第11頁，課件共84頁，創(chuàng)作于2023年2月-12-內(nèi)容安排UML概述理解需求需求，難在何處？以用例為中心組織需求基于用例的需求分析過程第12頁，課件共84頁，創(chuàng)作于2023年2月-13-需求：飲料問題我要一瓶飲料…差不多，但我要無糖飲料…很好，不過我要綠茶的…啊，沒有大瓶的…大瓶的無糖綠茶飲料難捕獲，易變！第13頁，課件共84頁，創(chuàng)作于2023年2月-14-需求：如此脆弱客戶/用戶的要求/想法/期望軟件設計軟件產(chǎn)品分析和設計編碼和測試驗收沒價值的

軟件需求補文檔第14頁，課件共84頁，創(chuàng)作于2023年2月-15-需求：也需要開發(fā)客戶/用戶的要求/想法/期望軟件設計軟件產(chǎn)品開發(fā)編碼和測試驗收有價值的

軟件需求分析和設計第15頁，課件共84頁，創(chuàng)作于2023年2月-16-獲取好的需求需求收集包括五個關鍵步驟找到可以幫助你理解這個系統(tǒng)的人傾聽這些相關人員的描述，并從他們的角度來理解系統(tǒng)利用一個容易理解的模型來描述用戶希望如何使用這個系統(tǒng)以及為他們提供的什么價值詳細地描述系統(tǒng)和客戶以及系統(tǒng)和外部系統(tǒng)之間的交互重構（refactor）這個詳細描述以保證它是可讀且易懂的第16頁，課件共84頁，創(chuàng)作于2023年2月-17-內(nèi)容安排UML概述理解需求需求，難在何處？以用例為中心組織需求基于用例的需求分析過程第17頁，課件共84頁，創(chuàng)作于2023年2月-18-需求問題：對策難捕獲易變從用戶視角看問題合理的結構用例第18頁，課件共84頁，創(chuàng)作于2023年2月-19-以用例為中心組織需求用例可用性可靠性網(wǎng)絡協(xié)議業(yè)務規(guī)則……硬件接口界面約束性能第19頁，課件共84頁，創(chuàng)作于2023年2月-20-內(nèi)容安排UML概述理解需求需求，難在何處？以用例為中心組織需求基于用例的需求分析過程第20頁，課件共84頁，創(chuàng)作于2023年2月-21-基于用例的需求分析過程1.獲取原始需求2.開發(fā)一個可以理解的需求2.1識別參與者2.2識別用例2.3構建用例圖3詳細、完整地描述需求進行用例闡述4重構用例模型4.1識別用例間的關系4.2對用例進行組織和分包第21頁，課件共84頁，創(chuàng)作于2023年2月-22-基于用例的需求分析過程1.獲取原始需求2.開發(fā)一個可以理解的需求2.1識別參與者2.2識別用例2.3構建用例圖3.詳細、完整地描述需求進行用例闡述4.重構用例模型4.1識別用例間的關系4.2對用例進行組織和分包第22頁，課件共84頁，創(chuàng)作于2023年2月-23-獲取需求的技巧技巧描述實地觀察直接觀察個人工作的情況，以發(fā)現(xiàn)現(xiàn)存的實踐方式和問題訪談從個人處收集特定信息特定群體調(diào)查對一組人員進行調(diào)查，以便了解工作態(tài)度和共同看法問卷調(diào)查收集詳細數(shù)據(jù)和統(tǒng)計意義上比較重要的數(shù)據(jù)用戶指導讓最終用戶告訴你，他們是如何操作系統(tǒng)的原型制作模擬一個無法直接測試的系統(tǒng)統(tǒng)計版本使用具有統(tǒng)計功能的應用程序來記錄用戶完成任務的方式行業(yè)知識收集和整理行業(yè)中的法律、法規(guī)，用戶所使用的規(guī)章制度、操作規(guī)程等內(nèi)容………第23頁，課件共84頁，創(chuàng)作于2023年2月-24-獲取需求：考勤卡應用程序初次訪談記錄

開發(fā)者：誰將使用這個應用程序？

客戶：所有用它來記錄可記帳以及不可記帳的工時的雇員

……

開發(fā)者：現(xiàn)在考勤卡應用程序是什么樣的？

客戶：每半個月就用一個Excel表格來記錄。每個雇員都將通過他的表格填好，然后用電子郵件發(fā)給我。這個表格相當標準：縱向是收費項目代碼，橫向是日期。雇員可以在每個條目上填寫說明。

開發(fā)者：這個收費項目代碼可以從什么地方得到？

……

開發(fā)者：誰來管理收費項目代碼？

客戶：嗯，必要的時候由我來添加這個代碼。而每個經(jīng)理總會告訴他的下屬應該填寫什么。

……第24頁，課件共84頁，創(chuàng)作于2023年2月-25-基于用例的需求分析過程1.獲取原始需求2.開發(fā)一個可以理解的需求2.1識別參與者2.2識別用例2.3構建用例圖：確定參與者和用例之間的關系3.詳細、完整地描述需求進行用例闡述4.重構用例模型4.1識別用例間的關系4.2對用例進行組織和分包第25頁，課件共84頁，創(chuàng)作于2023年2月-26-相關術語場景：是用來描述用戶和系統(tǒng)之間交互的順序的步驟

用例：是為了達到某一用戶目標而組合在一起的一組場景

用例圖：用來顯示在系統(tǒng)（或其它實體）內(nèi)的用例與系統(tǒng)參與者之間的關系

主要使用場合：需求獲取、定義、分析用例模型：是系統(tǒng)既定功能及系統(tǒng)環(huán)境的模型，并作為客戶和開發(fā)人員之間的契約。用例模型用作分析、設計和測試活動的基本輸入。第26頁，課件共84頁，創(chuàng)作于2023年2月-27-用例圖元素<<include>><<extend>>參與者用例系統(tǒng)邊界直接關聯(lián)擴展包含泛化注釋體注釋連接關聯(lián)第27頁，課件共84頁，創(chuàng)作于2023年2月-28-2.1識別參與者參與者，Actor關鍵詞：邊界參與者：在系統(tǒng)之外，透過系統(tǒng)邊界與系統(tǒng)進行有意義交互的任何事物第28頁，課件共84頁，創(chuàng)作于2023年2月-29-參與者要點系統(tǒng)外參與者代表在系統(tǒng)邊界之外的真實事物，并不是系統(tǒng)的成分系統(tǒng)邊界參與者透過系統(tǒng)邊界直接與系統(tǒng)交互，參與者的確定代表系統(tǒng)邊界的確定有意義的交互任何事物人、外系統(tǒng)、外部因素、時間第29頁，課件共84頁，創(chuàng)作于2023年2月-30-識別參與者：考勤卡系統(tǒng)開發(fā)者：誰將使用這個應用程序？

客戶：所有用它來記錄可記帳以及不可記帳的工時的雇員

……

開發(fā)者：現(xiàn)在考勤卡應用程序是什么樣的？

客戶：每半個月就用一個Excel表格來記錄。每個雇員都將通過他的表格填好，然后用電子郵件發(fā)給我。這個表格相當標準：縱向是收費項目代碼，橫向是日期。雇員可以在每個條目上填寫說明。

開發(fā)者：這個收費項目代碼可以從什么地方得到？

……

開發(fā)者：誰來管理收費項目代碼？

客戶：嗯，必要的時候由我（業(yè)務經(jīng)理）來添加這個代碼。而每個經(jīng)理總會告訴他的下屬應該填寫什么。

……第30頁，課件共84頁，創(chuàng)作于2023年2月-31-2.2識別用例關鍵詞：價值定義用例實例是系統(tǒng)執(zhí)行的一系列動作，這些動作將生成特定參與者可觀測的結果值一個用例定義一組用例實例簡潔：參與者使用系統(tǒng)達到目標第31頁，課件共84頁，創(chuàng)作于2023年2月-32-識別用例：考勤卡系統(tǒng)開發(fā)者：誰將使用這個應用程序？

客戶：所有用它來記錄可記帳以及不可記帳的工時的雇員

……

開發(fā)者：現(xiàn)在考勤卡應用程序是什么樣的？

客戶：每半個月就用一個Excel表格來記錄。每個雇員都將通過他的表格填好，然后用電子郵件發(fā)給我。這個表格相當標準：縱向是收費項目代碼，橫向是日期。雇員可以在每個條目上填寫說明。

開發(fā)者：這個收費項目代碼可以從什么地方得到？

……

開發(fā)者：誰來管理收費項目代碼？

客戶：嗯，必要的時候由我（業(yè)務經(jīng)理）來添加這個代碼。而每個經(jīng)理總會告訴他的下屬應該填寫什么。

……第32頁，課件共84頁，創(chuàng)作于2023年2月-33-用例要點可觀測→用例止于系統(tǒng)邊界結果值→用例是有意義的目標系統(tǒng)執(zhí)行→結果值由系統(tǒng)生成由參與者觀測→業(yè)務語言、用戶觀點一組用例實例→用例的粒度第33頁，課件共84頁，創(chuàng)作于2023年2月-34-要點：用例止于系統(tǒng)邊界描述交互，而不是內(nèi)在的系統(tǒng)活動第34頁，課件共84頁，創(chuàng)作于2023年2月-35-要點：有意義的目標第35頁，課件共84頁，創(chuàng)作于2023年2月-36-要點：結果值由系統(tǒng)生成系統(tǒng)需要處理的，由系統(tǒng)生成第36頁，課件共84頁，創(chuàng)作于2023年2月-37-要點：業(yè)務語言而非技術語言用戶詞匯，而不是技術詞匯如：發(fā)票，商品，洗衣機而不是：記錄，字段，COM，C++等第37頁，課件共84頁，創(chuàng)作于2023年2月-38-要點：用戶觀點而非系統(tǒng)觀點用戶觀點系統(tǒng)觀點第38頁，課件共84頁，創(chuàng)作于2023年2月-39-用例VS.功能呼叫某人接聽電話發(fā)送短信記住電話號碼……傳輸/接收電源/基站輸入輸出（顯示、鍵盤）電話簿管理……用戶觀點系統(tǒng)觀點第39頁，課件共84頁，創(chuàng)作于2023年2月-40-用例的命名執(zhí)行者視角：一個簡單、描述性的名稱，一般為帶有動作性的詞。第40頁，課件共84頁，創(chuàng)作于2023年2月-41-要點：用例粒度-1用例要有路徑，路徑要有步驟；而這一切都是可觀測的最常犯錯誤：粒度過細，陷入功能分解過細的粒度，一般都會導致技術語言的描述，而不再是業(yè)務語言第41頁，課件共84頁，創(chuàng)作于2023年2月-42-用例粒度-2把步驟當用例把系統(tǒng)活動當用例第42頁，課件共84頁，創(chuàng)作于2023年2月-43-用例粒度-3“四輪馬車”C(Create)

R(Read)

U(Update)

D(Delete)所有業(yè)務最終對會成為CRUD？CRUD能為Actor提供價值？CRUD掩蓋業(yè)務，銳變成關系數(shù)據(jù)庫的建模：“系統(tǒng)就是數(shù)據(jù)的增刪改查”關心數(shù)據(jù)的存儲和維護，反而忽略了用戶的目的第43頁，課件共84頁，創(chuàng)作于2023年2月-44-用例粒度-4如果確實是CRUD？如果CRUD不涉及復雜的交互，一個用例“管理××”即可不管是C、R、U、D，都是為了完成“管理”目標甚至很多種的基本數(shù)據(jù)管理都可以用一個用例表示第44頁，課件共84頁，創(chuàng)作于2023年2月-45-用例粒度-5靈活處理CRUD可以把包含復雜交互的路徑獨立出去形成用例第45頁，課件共84頁，創(chuàng)作于2023年2月-46-思考：識別用例-1Email客戶端（如：outlookexpress），A在北京發(fā)郵件給上海的B，系統(tǒng)提醒B你有“新郵件”，B收郵件錯誤第46頁，課件共84頁，創(chuàng)作于2023年2月-47-思考：識別用例-2第47頁，課件共84頁，創(chuàng)作于2023年2月-48-2.3構建用例圖第48頁，課件共84頁，創(chuàng)作于2023年2月-49-基于用例的需求分析過程1.獲取原始需求2.開發(fā)一個可以理解的需求2.1識別參與者2.2識別用例2.3構建用例圖3.詳細、完整地描述需求進行用例闡述4.重構用例模型(高級用例建模方法)4.1識別用例間的關系4.2對用例進行組織和分包第49頁，課件共84頁，創(chuàng)作于2023年2月-50-進行用例闡述：寫用例規(guī)約用例規(guī)約(UsecaseSpecification)：更進一步的精度用例文檔的核心，作為用例文檔的總圖進一步的精度：有層次的文檔文檔中每一句話都有其價值用例圖是骨架，而用例規(guī)約則是其內(nèi)在的肉第50頁，課件共84頁，創(chuàng)作于2023年2月-51-誰來寫用例文檔最完美：業(yè)務人員接受訓練，寫出優(yōu)美的用例文檔最現(xiàn)實：業(yè)務人員提供素材，開發(fā)人員寫用例文檔最糟糕：業(yè)務人員不管，完全由開發(fā)人員杜撰第51頁，課件共84頁，創(chuàng)作于2023年2月-52-用例規(guī)約組成用例名稱用例標識涉及的參與者描述用例的規(guī)格說明前置條件PreConditions后置條件PostConditions正常事件流Flowofevents備選事件流Alternateflow其它非功能需求、設計約束、尚存在的問題第52頁，課件共84頁，創(chuàng)作于2023年2月-53-前置、后置條件-1前置條件約束在用例開始前系統(tǒng)的狀態(tài)把它們看做是看門人，它阻止參與者觸發(fā)該用例直到滿足所有條件說明在用例觸發(fā)之前什么必須為真后置條件約束用例執(zhí)行后系統(tǒng)的狀態(tài)用例執(zhí)行后什么必須為真對于有多個事件流的用例，則應該有多個后置條件第53頁，課件共84頁，創(chuàng)作于2023年2月-54-前置、后置條件-2某些用例依賴于其他用例一個用例在離開系統(tǒng)時，可能是另一個用例的前置條件（例如：“登錄”和“管理系統(tǒng)”）有助于識別漏掉的用例如果一個用例的前置條件不能有執(zhí)行其他用例滿足，可能意味著丟失了用例（例如：“管理訂單”卻沒有“登錄”用例）第54頁，課件共84頁，創(chuàng)作于2023年2月-55-用例交互四部曲-事件流1.動作4.回應2.改變3.驗證系統(tǒng)寫：可觀測的、體現(xiàn)客戶利益的文字第55頁，課件共84頁，創(chuàng)作于2023年2月-56-事件流描述要點1.只書寫“可觀測”的2.使用主動語句3.句子必須以參與者或系統(tǒng)作為主語4.不要涉及界面細節(jié)5.分支和循環(huán)第56頁，課件共84頁，創(chuàng)作于2023年2月-57-要點1：只寫“可觀測”的系統(tǒng)通過ADO建立數(shù)據(jù)庫連接，傳送SQL查詢語句，從“商品表”查詢商品的詳細信息…系統(tǒng)按照查詢條件搜索商品的詳細信息第57頁，課件共84頁，創(chuàng)作于2023年2月-58-要點2：主動語句用戶輸入搜索條件，頁面顯示系統(tǒng)搜索的結果…出納員……系統(tǒng)……第58頁，課件共84頁，創(chuàng)作于2023年2月-59-要點3：以參與者或系統(tǒng)作主語參與者……系統(tǒng)……出納員接收顧客的付款—顧客的付款數(shù)可能高于商品總額出納員錄入顧客所付的現(xiàn)金總額系統(tǒng)顯示出應找還給顧客的余額，打印付款收據(jù)第59頁，課件共84頁，創(chuàng)作于2023年2月-60-要點4：不涉及界面細節(jié)會員從下拉框中選擇類別會員在相應文本框中輸入查詢條件會員點擊“確定”按鈕第60頁，課件共84頁，創(chuàng)作于2023年2月-61-要點5：分支和循環(huán)分支：放到擴展路徑參與者的選擇另一條成功線路系統(tǒng)進行驗證……循環(huán)：直接描述第61頁，課件共84頁，創(chuàng)作于2023年2月-62-用例規(guī)約：記錄時間UC01：“RecordTime”用例文檔用例名稱：RecordTime（記錄時間）用例標識：UC01涉及的參與者：雇員、系統(tǒng)管理員描述：雇員利用“RecordTime”用例來登記他們的工時 系統(tǒng)管理員用這個用例為任何雇員登記時間前置條件：用戶必須已經(jīng)登錄到這個系統(tǒng)后置條件：系統(tǒng)將雇員的工時正確的記錄到數(shù)據(jù)庫中第62頁，課件共84頁，創(chuàng)作于2023年2月-63-用例規(guī)約：記錄時間(續(xù))正常事件流（BasicFlow）：雇員查看當前時間之前輸入的數(shù)據(jù)；雇員從已有的支付號碼中選擇一個，這些收費代碼是按客戶和項目組織的；雇員從當前的時間段選擇一個日期；雇員輸入以正整數(shù)表示的工時；系統(tǒng)在視圖中顯示這個數(shù)據(jù)，并在以后的視圖中看到這個數(shù)據(jù)。備選事件流（AlternativeFlow）1：雇員更改他的時間雇員查看當前時間之前輸入的數(shù)據(jù)；雇員選擇一個已有的條目；雇員改變工時；在視圖中更新這個信息，并在以后的視圖中都可以看到。第63頁，課件共84頁，創(chuàng)作于2023年2月-64-用例規(guī)約：記錄時間(續(xù))非功能需求：無設計約束：無部署約束：用戶可以從客戶端或雇員的家中訪問到“RecordTime”用例，如果是從客戶端訪問，則要考慮到客戶端的防火墻未解決的問題雇員是否可以在以前的考勤卡上輸入和更改時間雇員是否可以在以后的考勤卡上輸入和更改時間，例如，在休假之前？第64頁，課件共84頁，創(chuàng)作于2023年2月-65-活動圖-簡述用例流程第65頁，課件共84頁，創(chuàng)作于2023年2月-66-活動圖ActivityDiagram通過動作來組織，主要用于描述某一方法、機制或用例的內(nèi)部行為活動（Activities）,whicharestepsintheworkflow.動作（Actions）,whicharestepswithinanactivity.Actionsmayoccurwhenenteringtheactivity,exitingtheactivity,whileinsidetheactivity,oruponaspecificevent.轉移（Transitions）、決策（Decision）、同步條（Synchronizations）業(yè)務對象（Businessobjects）起始狀態(tài)（Thestartstate）、終止狀態(tài)（Theendstate）第66頁，課件共84頁，創(chuàng)作于2023年2月-67-活動圖-推薦的使用場合分析用例：能直觀清晰地分析用例，了解應當采取哪些動作以及這些動作之間的依賴關系。一張完整的活動圖是所有用例的集成圖理解牽涉多個用例的工作流：在難于區(qū)分不同用例而對整個系統(tǒng)的工作過程又十分清楚時，可以先構造活動圖，然后用切片技術派生用例圖處理多線程應用：采用“分層抽象，逐步細化”的原則描述多線程第67頁，課件共84頁，創(chuàng)作于2023年2月-68-基于用例的需求分析過程1.獲取原始需求2.開發(fā)一個可以理解的需求2.1識別參與者2.2識別用例2.3構建用例圖3詳細、完整地描述需求進行用例闡述4重構用例模型(高級用例建模方法)4.1識別用例間的關系4.2對用例進行組織和分包第68頁，課件共84頁，創(chuàng)作于2023年2月-69-4.1用例關系<<include>><<extend>>ExtendIncludeGeneralization第69頁，課件共84頁，創(chuàng)作于2023年2月-70-通過關系整理文檔Extend分離擴展路徑Include提取公共步驟，便于復用Generalization同一業(yè)務目的的不同技術實現(xiàn)第70頁，課件共84頁，創(chuàng)作于2023年2月-71-擴展關系基用例路徑本身是完整的，可能是一條擴展路徑擴展路徑步驟多擴展路徑內(nèi)部還有擴展點－擴展之擴展第71頁，課件共84頁，創(chuàng)作于2023年2月-72-擴展關系誤用第72頁，課件共84頁，創(chuàng)作于2023年2月-73-識別擴展點思路執(zhí)行者的選擇系統(tǒng)驗證步驟失敗……必須是系統(tǒng)能感知的第73頁，課件共84頁，創(chuàng)作于2023年2月-74-包含關系某些步驟在多個用例重復出現(xiàn)，且單獨形成價值用例步驟較多時，可用Include簡化（慎用）第74頁，課件共84頁，創(chuàng)作于2023年2月-75-包含關系誤用第75頁，課件共84頁，創(chuàng)作于2023年2月-76-泛化關系同一業(yè)務目的不同技術實現(xiàn)：一個用例可以特化另一個更普通用例（更普通用例泛化特殊用例）UML1.5:用例間的泛化關系表明子用例包含父用例中定義的所有屬性、行為序列和擴展點，并且參與父用例中所有的關系第76頁，課件共84頁，創(chuàng)作于2023年2月-77-用例關系：擴展VS.泛化采用不同關系，文檔結構不同第77頁，課件共84頁，創(chuàng)作于2023年2月-78-重構后的用例圖：考勤卡系統(tǒng)第78頁，課件共84頁，創(chuàng)作于2023年2月-79-4.2為什么要對用例進行分級用例和開發(fā)周期開發(fā)周期是圍繞用例的需求來組織的一個開發(fā)周期要被指派一個到多個用例，如果完全版