表2用例描述格式課件

第4章建立用例模型4.1需求獲取4.2分析需求4.3用例在需求分析中的使用4.4識別參與者4.5確定用例4.6用例的粒度4.7用例間的關(guān)系4.8用例描述4.9用例建模9/26/20231第4章建立用例模型4.1需求獲取8/8/20231需求分析就是分析軟件用戶的需求是什么。需求分析之所以重要，就因為他具有決策性、方向性和策略性的作用，它在軟件開發(fā)過程中具有舉足輕重的地位，在一個大型軟件系統(tǒng)的開發(fā)中，他的作用要遠(yuǎn)遠(yuǎn)大于程序設(shè)計。需求分析的任務(wù)就是解決“做什么”的問題，就是要全面地理解用戶的各項要求，并準(zhǔn)確地表達(dá)所接受的用戶需求。9/26/20232需求分析就是分析軟件用戶的需求是什么。8/8/20232整個軟件需求工程研究領(lǐng)域劃分為需求開發(fā)和需求管理兩部分。9/26/20233整個軟件需求工程研究領(lǐng)域劃分為需求開發(fā)和需求管理兩部分。8/4.1需求獲取需求是客戶在項目立項時就有的一個遠(yuǎn)景?？蛻粜枨髮Q定在整個項目中需要承辦方具體做些什么，即承辦方的任務(wù)。承辦方在明確了需求后，就會開始后期的設(shè)計、開發(fā)、測試、部署等工作。9/26/202344.1需求獲取需求是客戶在項目立項時就有的一個遠(yuǎn)景?？蛻粜?.1需求獲取需求獲取在軟件工程中非常重要，因為后續(xù)的設(shè)計、開發(fā)等都基于需求。如果需求獲取不正確或在需求開發(fā)過程中很多功能沒有挖掘出來，那么在后期選擇彌補(bǔ)時，將會造成項目延期以及成本大幅度增加的嚴(yán)重后果。如何獲取需求是擺在承辦方面前的首要任務(wù)。9/26/202354.1需求獲取需求獲取在軟件工程中非常重要，因為后續(xù)的設(shè)計4.1需求獲取需求獲取的目的是通過各種途徑獲取用戶的需求信息，由于在實際工作中，大部分客戶無法完整地講述其需求，因此需求獲取是一件看似簡單，做起來卻很難的一件事情。在需求獲取過程中，主要需要弄清楚3個問題，即：明確需要獲取的信息（What）明確所獲取信息的來源和渠道（Where）怎樣獲取需求（How）。9/26/202364.1需求獲取需求獲取的目的是通過各種途徑獲取用戶的需求信4.1需求獲取(1)明確需要獲取的信息（What）需求分析師應(yīng)在需求獲取前明確需要獲取的信息，以確保在實施需求獲取時有的放矢。通常需求獲取需要獲取的信息包括三大類：a.與問題域相關(guān)的背景信息（如業(yè)務(wù)資料、組織結(jié)構(gòu)圖和業(yè)務(wù)處理流程等）；b.與要求解決的問題直接相關(guān)的信息；c.用戶對系統(tǒng)的特別期望與施加的任何約束信息。9/26/202374.1需求獲取(1)明確需要獲取的信息（What）8/84.1需求獲取(2)明確所獲取信息的來源和渠道（Where）需求分析師還應(yīng)確定獲取需求信息的來源與渠道，以提高需求分析師在需求獲取階段的工作效率，使得所收集的信息更加有價值、更加全面。需求信息的來源通常包括：a.來自客戶的需求；b.競爭對手的產(chǎn)品優(yōu)勢與不足；c.國家政策、業(yè)務(wù)規(guī)則以及相關(guān)行業(yè)標(biāo)準(zhǔn)；d.實施產(chǎn)品設(shè)計所需滿足的需求；e.執(zhí)行測試驗證工作所需滿足的需求；f.實施系統(tǒng)安裝、維護(hù)所需滿足的需求。9/26/202384.1需求獲取(2)明確所獲取信息的來源和渠道（Wher4.1需求獲取獲取需求信息的渠道包括：a.用戶或客戶b.公司研發(fā)管理部門c.公司技術(shù)管理部門d.項目實施部門e.營銷管理部門f.舊有系統(tǒng)的研發(fā)項目組g.來自項目組內(nèi)9/26/202394.1需求獲取獲取需求信息的渠道包括：8/8/202394.1需求獲取(3)怎樣獲取需求（How）需求分析師應(yīng)選擇至少一種需求獲取技術(shù)獲取相關(guān)的需求，作為需求分析的依據(jù)。需求獲取技術(shù)包括但不限于：a.用戶訪談b.用戶調(diào)查c.現(xiàn)場觀摩用戶的工作流程，觀察用戶的實際操作d.從行業(yè)標(biāo)準(zhǔn)、規(guī)范中提取需求e.文檔挖掘f.需求討論會g.原型法9/26/2023104.1需求獲取(3)怎樣獲取需求（How）8/8/2024.2分析需求通過需求獲取，總結(jié)出客戶服務(wù)系統(tǒng)主要功能需求包括以下幾個方面：(1)客戶可以通過不同的方式（如電話，互聯(lián)網(wǎng)）對軟件產(chǎn)品或項目提出使用中的BUG或疑難問題以及投訴建議等內(nèi)容。(2)客戶服務(wù)人員應(yīng)當(dāng)能保存客戶資料，保存客戶歷次來電內(nèi)容，并對客戶提出的問題及時給予解答，不能在電話中處理的應(yīng)當(dāng)交由相關(guān)技術(shù)工程師繼續(xù)跟進(jìn)處理。(3)對需要安排上門維護(hù)的申請應(yīng)能及時反映給相關(guān)部門領(lǐng)導(dǎo)，并由其作出派工處理。(4)應(yīng)能及時反饋有派工任務(wù)的消息給相關(guān)技術(shù)工程師，并能保存其處理結(jié)果。(5)各部門領(lǐng)導(dǎo)應(yīng)能對投訴的申請給予及時處理，并能保存處理結(jié)果。(6)公司領(lǐng)導(dǎo)和部門領(lǐng)導(dǎo)應(yīng)能及時查詢客戶的來電內(nèi)容，了解產(chǎn)品使用情況及客戶服務(wù)人員的售后服務(wù)質(zhì)量等相關(guān)業(yè)務(wù)的綜合統(tǒng)計信息。以上需求信息需要進(jìn)行詳細(xì)的分析、歸納。9/26/2023114.2分析需求通過需求獲取，總結(jié)出客戶服務(wù)系統(tǒng)主要功能需求4.2分析需求經(jīng)過分析，為滿足上述需求的客戶服務(wù)系統(tǒng)應(yīng)包括以下幾個模塊：(1)基礎(chǔ)資料維護(hù)模塊。包括客戶基礎(chǔ)資料錄入修改，客戶服務(wù)系統(tǒng)用戶信息的添加、刪除和修改，軟件產(chǎn)品的基礎(chǔ)資料維護(hù)，已上線項目的基礎(chǔ)資料維護(hù)以及FAQ經(jīng)驗庫的數(shù)據(jù)維護(hù)。(2)客戶服務(wù)業(yè)務(wù)處理模塊。包括客戶咨詢服務(wù)處理，故障申報處理，投訴處理，客戶服務(wù)人員回訪處理，維護(hù)人員上門處理，部門領(lǐng)導(dǎo)派工處理。(3)信息查詢統(tǒng)計模塊。包括基礎(chǔ)資料查詢統(tǒng)計，客戶咨詢的查詢與統(tǒng)計，派工單完成情況，回訪情況，維護(hù)報告查詢統(tǒng)計以及相關(guān)報表的查詢。9/26/2023124.2分析需求經(jīng)過分析，為滿足上述需求的客戶服務(wù)系統(tǒng)應(yīng)包括4.2分析需求軟件系統(tǒng)的需求分析可以由產(chǎn)品工程師或系統(tǒng)分析師或兩者分階段合作完成全部的需求分析工作。其主要任務(wù)是逐步細(xì)化所有的軟件功能，找出系統(tǒng)各元素間的聯(lián)系、接口特性和設(shè)計上的限制，分析它們是否滿足需求，剔除不合理部分，增加需要部分。最后，綜合成系統(tǒng)的解決方案，給出待開發(fā)系統(tǒng)的詳細(xì)邏輯模型。其主要包括以下幾個步驟：9/26/2023134.2分析需求軟件系統(tǒng)的需求分析可以由產(chǎn)品工程師或系統(tǒng)分析4.2分析需求(1)提取出核心、主要、急迫的業(yè)務(wù)，明晰業(yè)務(wù)流程通過需求調(diào)研，我們會發(fā)現(xiàn)用戶各方面的業(yè)務(wù)很多，從大處著眼，包括用戶的各種業(yè)務(wù)項目、業(yè)務(wù)流程，再明細(xì)到業(yè)務(wù)過程的每一個單據(jù)，每一條記錄。從用戶繁雜的業(yè)務(wù)中進(jìn)行業(yè)務(wù)、業(yè)務(wù)流程的提取。需要分析用戶的這個業(yè)務(wù)流程中哪些是系統(tǒng)能幫助管理的，哪些是要在系統(tǒng)外處理的，充分分析用戶現(xiàn)有的業(yè)務(wù)和業(yè)務(wù)流程。9/26/2023144.2分析需求(1)提取出核心、主要、急迫的業(yè)務(wù)，明晰業(yè)4.2分析需求(2)運(yùn)用管理思想，優(yōu)化業(yè)務(wù)流程客戶服務(wù)系統(tǒng)是管理軟件產(chǎn)品，要幫助用戶解決的是管理問題，那么用戶是這樣的業(yè)務(wù)流程，就需要分析這樣的流程合理嗎？還有缺陷嗎？怎樣做能提高效率、解決問題？可以運(yùn)用更先進(jìn)的管理思想嗎？……。一般情況下，需要從兩個方面考慮業(yè)務(wù)流程的優(yōu)化。一是我們采用了網(wǎng)絡(luò)計算機(jī)這些新的技術(shù)手段，較之原先手工、電話等方式在信息的傳遞、信息的共享、數(shù)據(jù)的處理等方面將會帶來新的方式，必將改變原有的業(yè)務(wù)流程。另一方面就是我們根據(jù)對用戶業(yè)務(wù)的理解，考慮是否可以運(yùn)用先進(jìn)的管理思想，進(jìn)行現(xiàn)有業(yè)務(wù)流程的重組或優(yōu)化。9/26/2023154.2分析需求(2)運(yùn)用管理思想，優(yōu)化業(yè)務(wù)流程8/8/24.2分析需求(3)進(jìn)行業(yè)務(wù)分類，規(guī)劃系統(tǒng)藍(lán)圖明確以上內(nèi)容后就可以描繪系統(tǒng)藍(lán)圖了。系統(tǒng)有幾個子系統(tǒng)，每個子系統(tǒng)有哪些模塊，各個模塊處理哪些業(yè)務(wù)，等等。以上內(nèi)容主要是針對系統(tǒng)功能性需求，除此之外，系統(tǒng)還有性能需求也需要明確。9/26/2023164.2分析需求(3)進(jìn)行業(yè)務(wù)分類，規(guī)劃系統(tǒng)藍(lán)圖8/8/24.3用例在需求分析中的使用規(guī)劃出了軟件的功能模塊，只是軟件的功能框架結(jié)構(gòu)，下一步就需要明確描述每個模塊的具體內(nèi)容。包含什么內(nèi)容、能做什么操作，每一個功能點(diǎn)的說明、業(yè)務(wù)規(guī)則、詳細(xì)功能描述等等。這些軟件需求規(guī)格必須描述的內(nèi)容需要有個標(biāo)準(zhǔn)的表現(xiàn)方式。9/26/2023174.3用例在需求分析中的使用規(guī)劃出了軟件的功能模塊，只是軟4.3用例在需求分析中的使用用例(UseCase)是一種描述系統(tǒng)需求的方法，使用用例的方法來描述系統(tǒng)需求的過程就是用例建模。用例模型包括用例圖和用例描述。用例圖主要由以下模型元素構(gòu)成：9/26/2023184.3用例在需求分析中的使用用例(UseCase)是4.3用例在需求分析中的使用(1)參與者(Actor)參與者是指存在于被定義系統(tǒng)外部并與該系統(tǒng)發(fā)生交互的人或其他系統(tǒng)，他們代表的是系統(tǒng)的使用者或使用環(huán)境。9/26/2023194.3用例在需求分析中的使用(1)參與者(Actor)4.3用例在需求分析中的使用(2)用例(UseCase)用例用于表示系統(tǒng)所提供的服務(wù)，它定義了系統(tǒng)是如何被參與者所使用的，它描述的是參與者為了使用系統(tǒng)所提供的某一完整功能而與系統(tǒng)之間發(fā)生的一段對話。9/26/2023204.3用例在需求分析中的使用(2)用例(UseCas4.3用例在需求分析中的使用(3)關(guān)聯(lián)(Association)關(guān)聯(lián)用于表示參與者和用例之間的對應(yīng)關(guān)系，它表示參與者使用了系統(tǒng)中的哪些服務(wù)（用例），或者說系統(tǒng)所提供的服務(wù)（用例）是被哪些參與者所使用的。9/26/2023214.3用例在需求分析中的使用(3)關(guān)聯(lián)(Associ4.3用例在需求分析中的使用以課程注冊系統(tǒng)為例，當(dāng)參與者是學(xué)生時，學(xué)生使用該系統(tǒng)可以進(jìn)行登錄系統(tǒng)、注冊課程和查看報告的操作。9/26/2023224.3用例在需求分析中的使用以課程注冊系統(tǒng)為例，當(dāng)參與者是4.3用例在需求分析中的使用用例方法完全站在用戶的角度上（從系統(tǒng)的外部）來描述系統(tǒng)的功能。在用例方法中，把被定義系統(tǒng)看作是一個黑箱，我們并不關(guān)心系統(tǒng)內(nèi)部是如何完成它所提供的功能的。用例方法首先描述了被定義系統(tǒng)有哪些外部使用者（抽象成為Actor），這些使用者與被定義系統(tǒng)發(fā)生交互；針對每一參與者，用例方法又描述了系統(tǒng)為這些參與者提供了什么樣的服務(wù)（抽象成為UseCase），或者說系統(tǒng)是如何被這些參與者使用的。所以從用例圖中，我們可以得到對于被定義系統(tǒng)的一個總體印象。9/26/2023234.3用例在需求分析中的使用用例方法完全站在用戶的角度上（4.3用例在需求分析中的使用與傳統(tǒng)的功能分解方式相比，用例方法完全是從外部來定義系統(tǒng)的功能，它把需求與設(shè)計完全分離開來。在面向?qū)ο蟮姆治鲈O(shè)計方法中，用例模型主要用于表述系統(tǒng)的功能性需求，系統(tǒng)設(shè)計主要由對象模型來記錄描述。另外，用例定義了系統(tǒng)功能的使用環(huán)境與上下文，每一個用例描述的是一個完整的系統(tǒng)服務(wù)。用例方法比傳統(tǒng)的SRS更易于被用戶所理解，它可以作為開發(fā)人員和用戶之間針對系統(tǒng)需求進(jìn)行溝通的一個有效手段。9/26/2023244.3用例在需求分析中的使用與傳統(tǒng)的功能分解方式相比，用例4.3用例在需求分析中的使用在RUP中，用例被作為整個軟件開發(fā)流程的基礎(chǔ)，很多類型的開發(fā)活動都把用例作為一個主要的輸入制品（Artifact），如項目管理、分析設(shè)計、測試等。根據(jù)用例來對目標(biāo)系統(tǒng)進(jìn)行測試，可以根據(jù)用例中所描述的環(huán)境和上下文來完整地測試一個系統(tǒng)服務(wù)，可以根據(jù)用例的各個場景（Scenario）來設(shè)計測試用例，完全地測試用例的各種場景可以保證測試的完備性。9/26/2023254.3用例在需求分析中的使用在RUP中，用例被作為整個軟件4.4識別參與者客戶服務(wù)系統(tǒng)是對公司和客戶進(jìn)行統(tǒng)一管理的系統(tǒng)，根據(jù)客戶服務(wù)系統(tǒng)案例需求說明書，具體包括以下幾個方面：(1)基礎(chǔ)資料維護(hù)。包括系統(tǒng)管理員添加、刪除、修改客戶服務(wù)系統(tǒng)賬戶信息，添加、修改、刪除公司產(chǎn)品及項目信息；客戶服務(wù)人員添加、修改、刪除客戶資料信息，添加、修改、刪除經(jīng)驗庫信息等。(2)業(yè)務(wù)處理。包括客戶服務(wù)人員新增、修改、刪除客戶咨詢信息；維護(hù)人員處理客戶問題、填寫維護(hù)報告；部門領(lǐng)導(dǎo)處理投訴，安排任務(wù)等。(3)統(tǒng)計查詢。包括客戶資料查詢、客戶來電咨詢查詢、經(jīng)驗庫查詢、客戶服務(wù)系統(tǒng)用戶信息查詢、回訪任務(wù)及維護(hù)報告查詢等。明確以上信息后，分析系統(tǒng)的參與者。9/26/2023264.4識別參與者客戶服務(wù)系統(tǒng)是對公司和客戶進(jìn)行統(tǒng)一管理的系4.4識別參與者對于這個系統(tǒng)，通過需求陳述文檔，可以得到以下一些信息：系統(tǒng)管理員維護(hù)系統(tǒng)用戶帳號和產(chǎn)品項目信息?？蛻舴?wù)人員維護(hù)客戶資料、客戶咨詢以及經(jīng)驗庫信息。維護(hù)人員填寫維護(hù)報告。部門領(lǐng)導(dǎo)處理投訴。所以創(chuàng)建以下參與者：系統(tǒng)管理員、客戶服務(wù)人員、維護(hù)人員、部門領(lǐng)導(dǎo)。9/26/2023274.4識別參與者對于這個系統(tǒng)，通過需求陳述文檔，可以得到以4.4識別參與者參與者是在系統(tǒng)之外，透過系統(tǒng)邊界與系統(tǒng)進(jìn)行有意義交互的任何事物。通俗地講，參與者就是我們所要定義系統(tǒng)的使用者。尋找參與者可以從以下問題入手：(1)系統(tǒng)開發(fā)完成之后，有哪些人會使用這個系統(tǒng)？(2)系統(tǒng)需要從哪些人或其他系統(tǒng)中獲得數(shù)據(jù)？(3)系統(tǒng)會為哪些人或其他系統(tǒng)提供數(shù)據(jù)？(4)系統(tǒng)需要與哪些其他系統(tǒng)交互？(5)系統(tǒng)是由誰來維護(hù)和管理并保持其正常運(yùn)行？(6)系統(tǒng)需要應(yīng)付（處理）哪些硬設(shè)備？(7)誰（或什么）對系統(tǒng)運(yùn)行產(chǎn)生的結(jié)果感興趣？(8)有沒有自動發(fā)生的事件？9/26/2023284.4識別參與者參與者是在系統(tǒng)之外，透過系統(tǒng)邊界與系統(tǒng)進(jìn)行4.4識別參與者在這里需要注意的是：系統(tǒng)參與者一定是與系統(tǒng)有直接聯(lián)系的事物，這里事物包括人和其他系統(tǒng)?！爸苯勇?lián)系”是個什么概念呢？在客戶服務(wù)系統(tǒng)中，客戶打電話給客戶服務(wù)人員反饋問題，客戶服務(wù)通過系統(tǒng)對反饋的問題進(jìn)行處理，在這個業(yè)務(wù)過程中，客戶并沒有直接操作客戶服務(wù)系統(tǒng)，就沒有直接聯(lián)系，所以客戶不是系統(tǒng)的參與者。這樣的例子還有很多，比如超市的收銀系統(tǒng)，收銀員是該系統(tǒng)的參與者，而超市客戶則不是；銀行系統(tǒng)中，銀行的窗口服務(wù)員是參與者，而在窗口存錢或取錢的客戶不是參與者。但在銀行ATM系統(tǒng)中，客戶從銀行ATM機(jī)存取款，客戶是ATM系統(tǒng)中的參與者。9/26/2023294.4識別參與者在這里需要注意的是：系統(tǒng)參與者一定是與系統(tǒng)4.5確定用例找到參與者之后，就需要根據(jù)參與者來確定系統(tǒng)的用例。對于每一個參與者，相對應(yīng)的用例如下：9/26/2023304.5確定用例找到參與者之后，就需要根據(jù)參與者來確定系統(tǒng)的4.5確定用例客戶服務(wù)人員：(1)登錄系統(tǒng)(2)查詢客戶信息及咨詢記錄(3)查詢經(jīng)驗庫信息(4)查詢基礎(chǔ)資料信息(5)補(bǔ)充完善經(jīng)驗庫信息(6)維護(hù)客戶資料(7)維護(hù)來電記錄9/26/2023314.5確定用例客戶服務(wù)人員：8/8/2023314.5確定用例維護(hù)人員：(1)查詢自己的派工單及報告信息(2)接受并處理自己的派工單(3)填寫報告9/26/2023324.5確定用例維護(hù)人員：8/8/2023324.5確定用例系統(tǒng)管理員：(1)管理用戶(2)維護(hù)基礎(chǔ)資料(3)維護(hù)系統(tǒng)9/26/2023334.5確定用例系統(tǒng)管理員：8/8/2023334.5確定用例部門領(lǐng)導(dǎo)：(1)查詢客戶資料及咨詢信息(2)查詢項目及產(chǎn)品信息(3)查詢維護(hù)人員派工單的執(zhí)行情況(4)安排派工任務(wù)9/26/2023344.5確定用例部門領(lǐng)導(dǎo)：8/8/2023344.5確定用例確定用例主要是看各參與者需要系統(tǒng)提供什么樣的服務(wù)，或者說參與者是如何使用系統(tǒng)的，用例命名往往采用動賓結(jié)構(gòu)。參與者與用例連起來讀，往往是一條通順的句子，例如：客戶服務(wù)人員（參與者）維護(hù)客戶資料（用例）。9/26/2023354.5確定用例確定用例主要是看各參與者需要系統(tǒng)提供什么樣的4.5確定用例尋找用例可以從以下問題入手（針對每一個參與者）：(1)參與者為什么要使用該系統(tǒng)？(2)參與者是否會在系統(tǒng)中創(chuàng)建、修改、刪除、訪問、存儲數(shù)據(jù)？如果是的話，參與者又是如何來完成這些操作的？(3)參與者是否會將外部的某些事件通知給該系統(tǒng)？(4)系統(tǒng)是否會將內(nèi)部的某些事件通知該參與者？9/26/2023364.5確定用例尋找用例可以從以下問題入手（針對每一個參與者4.6用例的粒度對于一個系統(tǒng)來說，不同的人進(jìn)行用例分析后得到的用例數(shù)目有多有少。如果用例粒度很大，那么得到的用例數(shù)就會很少，如果用例粒度很小，那么得到的用例數(shù)就會很多。那么到底多大的粒度才是比較合適的？9/26/2023374.6用例的粒度對于一個系統(tǒng)來說，不同的人進(jìn)行用例分析后得4.6用例的粒度用例就是客戶付錢給我們，要我們幫助解決的問題。這些問題是軟件系統(tǒng)的重心所在，也是客戶的價值所在。當(dāng)客戶來找我們解決問題時，如同一個病人去找醫(yī)生看病。這個病可能是大病，也可能是小病。正如醫(yī)生無法決定病人得什么病一樣，我們也無法決定客戶所遇到的問題，我們所能選擇的只是解決這些問題的方案。所以用例（大小）粒度的決定在于客戶，用例的關(guān)鍵在于準(zhǔn)確反映客戶需求。9/26/2023384.6用例的粒度用例就是客戶付錢給我們，要我們幫助解決的問4.6用例的粒度用例是一種用來探索需求的技術(shù)，而需求和設(shè)計之間的區(qū)別在于需求解決的是系統(tǒng)“做什么”的問題；而設(shè)計則是針對需求中提出的問題，解決系統(tǒng)該“怎么做”的問題。需求調(diào)研的過程是發(fā)現(xiàn)和界定問題的過程，設(shè)計的過程是尋找解決方案的過程。需求分析的思維方式是總結(jié)和抽象，系統(tǒng)設(shè)計的思維方式是分解和細(xì)化。9/26/2023394.6用例的粒度用例是一種用來探索需求的技術(shù)，而需求和設(shè)計4.6用例的粒度在確定用例過程中，主要有兩個方面的問題會迷惑分析者。其一是當(dāng)分析人員面對具有業(yè)務(wù)流程的用例時該如何處理；其二是面對具有功能分解的用例時如何處理。9/26/2023404.6用例的粒度在確定用例過程中，主要有兩個方面的問題會迷4.6用例的粒度具有業(yè)務(wù)流程的用例是指某個用例需要分幾個業(yè)務(wù)階段來完成，如客戶服務(wù)系統(tǒng)中維護(hù)人員接受派工單需要首先查看到派工單，然后選擇接受派工單。那么對于查看派工單和接受派工單，究竟是作為一個用例好，還是作為兩個用例好？我們對這類問題處理的原則是什么？9/26/2023414.6用例的粒度具有業(yè)務(wù)流程的用例是指某個用例需要分幾個業(yè)4.6用例的粒度用例是被從現(xiàn)實的場景中抽象出來的。如果這些場景有緊密的聯(lián)系（高內(nèi)聚），且能真正反映用戶的需求，那么用用例技術(shù)來組織它們則可以復(fù)用這些場景中的步驟描述，從而達(dá)到事倍功半的效果。在該例中，查看派工單和接受派工單兩個步驟的真正目的就是讓維護(hù)人員接受派工任務(wù)，用戶的需求也在于此，這兩個步驟是緊密聯(lián)系在一起的，所以把它們作為一個用例。9/26/2023424.6用例的粒度用例是被從現(xiàn)實的場景中抽象出來的。如果這些4.6用例的粒度具有功能分解的用例是指該用例往往可以分解為多個用例，如：維護(hù)客戶資料，在該用例中客戶服務(wù)人員可以做3件事：增加一條客戶資料、修改一條客戶資料、刪除一條客戶資料，那么分析人員可以有兩種方案，第一種方案是把這個用例單獨(dú)看作一個用例來描述，第二種方案則是分成3個用例來描述。9/26/2023434.6用例的粒度具有功能分解的用例是指該用例往往可以分解為4.6用例的粒度不同的人對這個問題會有不同的看法。從捕獲用戶需求的角度考慮，建議采用第一種方案，采用第二個方案的主要問題是限制了分析人員的思路。雖然從系統(tǒng)實現(xiàn)的角度看，對客戶資料的操作有添加、刪除、修改等，但事實上，用戶真正目的可能并不是對記錄的添加、修改和刪除，而是別的目的。如維護(hù)人員填寫維護(hù)信息，雖然這個要求會涉及到維護(hù)信息的增加、刪除和修改，但如果采用第二個方案有可能忽視了維護(hù)人員報告維護(hù)信息這個真正的用戶需求。9/26/2023444.6用例的粒度不同的人對這個問題會有不同的看法。8/8/4.7用例間的關(guān)系用例之間本來是獨(dú)立的、并行的，但是某些時候用例之間確實是具有一定的業(yè)務(wù)關(guān)系，例如客戶在瀏覽Web站點(diǎn)時可以選擇是否在線購買商品，“瀏覽Web站點(diǎn)”用例與“購買商品”用例之間就存在一定的關(guān)系。需要有一種方法來清楚地描述這樣的需求。9/26/2023454.7用例間的關(guān)系用例之間本來是獨(dú)立的、并行的，但是某些時4.7用例間的關(guān)系這種需求可以通過描述用例間的關(guān)系來表達(dá)?？蛻粼跒g覽Web站點(diǎn)時可以選擇是否在線購買商品，“瀏覽Web站點(diǎn)”用例與“購買商品”用例之間可以通過擴(kuò)展關(guān)系來描述：“購買商品”用例是“瀏覽Web站點(diǎn)”用例的擴(kuò)展。用例與用例之間的關(guān)系有三種：包含、擴(kuò)展和泛化。9/26/2023464.7用例間的關(guān)系這種需求可以通過描述用例間的關(guān)系來表達(dá)。4.7用例間的關(guān)系這幾種關(guān)系都是從現(xiàn)有的用例中抽取出部分信息，然后通過不同的方法來重用這部分信息，以減少模型維護(hù)的工作量。9/26/2023474.7用例間的關(guān)系8/8/2023474.7用例間的關(guān)系包含（include）關(guān)系包含關(guān)系是把幾個用例的公共行為分離成一個單獨(dú)的用例，使這幾個用例與該單獨(dú)的用例之間所建立的關(guān)系。被抽取出來的單獨(dú)的用例叫做被包含用例（Inclusion），而抽取出公共用例的幾個用例稱為基礎(chǔ)用例（Base）。具體地講，就是將被包含用例的業(yè)務(wù)插入到基礎(chǔ)用例的業(yè)務(wù)中。UML中，用例之間的包含關(guān)系是由基礎(chǔ)用例指向被包含用例的一條虛線箭頭來表示的，線上加構(gòu)造型<<include>>。9/26/2023484.7用例間的關(guān)系包含（include）關(guān)系8/8/204.7用例間的關(guān)系在ATM機(jī)中，如果查詢、取現(xiàn)、轉(zhuǎn)帳這三個用例都需要打印一個回執(zhí)給客戶，我們就可以把打印回執(zhí)這一部分內(nèi)容提取出來，抽象成為一個單獨(dú)的用例“打印回執(zhí)”，而原有的查詢、取現(xiàn)、轉(zhuǎn)帳三個例都會包含這個用例。每當(dāng)以后要對打印回執(zhí)部分的需求進(jìn)行修改時，就只需要改動一個用例，而不用在每一個用例都作相應(yīng)修改，這樣就提高了用例模型的可維護(hù)性。9/26/2023494.7用例間的關(guān)系在ATM機(jī)中，如果查詢、取現(xiàn)、轉(zhuǎn)帳這三個4.7用例間的關(guān)系9/26/2023504.7用例間的關(guān)系8/8/2023504.7用例間的關(guān)系擴(kuò)展（extend）關(guān)系擴(kuò)展（extend）關(guān)系是指基礎(chǔ)用例（Base）中定義有一至多個已命名的擴(kuò)展點(diǎn)，擴(kuò)展關(guān)系是指將擴(kuò)展用例（Extension）的業(yè)務(wù)過程在一定的條件下按照相應(yīng)的擴(kuò)展點(diǎn)插入到基礎(chǔ)用例（Base）中。對于包含關(guān)系而言，子用例中的業(yè)務(wù)過程是一定要插入到基礎(chǔ)用例中去的，并且插入點(diǎn)只有一個。而擴(kuò)展關(guān)系可以根據(jù)一定的條件來決定是否將擴(kuò)展用例的業(yè)務(wù)過程插入基礎(chǔ)用例業(yè)務(wù)過程，并且插入點(diǎn)可以有多個。UML中，用例之間的擴(kuò)展關(guān)系是由擴(kuò)展用例指向基礎(chǔ)用例的一條帶箭頭的虛線表示的，線上加構(gòu)造型<<extend>>。9/26/2023514.7用例間的關(guān)系擴(kuò)展（extend）關(guān)系8/8/20234.7用例間的關(guān)系例如對于電話業(yè)務(wù)，可以在基本通話（Call）業(yè)務(wù)上擴(kuò)展出一些增值業(yè)務(wù)，如：呼叫等待（CallWaiting）和呼叫轉(zhuǎn)移（CallTransfer）。在這個例子中，呼叫等待和呼叫轉(zhuǎn)移都是對基本通話用例的擴(kuò)展，但是這兩個用例只有在一定的條件下（如應(yīng)答方正忙或應(yīng)答方無應(yīng)答）才會將被擴(kuò)展用例的事件流嵌入基本通話用例的擴(kuò)展點(diǎn)，并重用基本通話用例中的事件流。9/26/2023524.7用例間的關(guān)系例如對于電話業(yè)務(wù)，可以在基本通話（Cal4.7用例間的關(guān)系9/26/2023534.7用例間的關(guān)系8/8/2023534.7用例間的關(guān)系泛化（generalization）關(guān)系當(dāng)多個用例共同擁有一種類似的結(jié)構(gòu)和行為的時候，我們可以將它們的共性抽象成為父用例，其他用例作為泛化關(guān)系中的子用例。在用例的泛化關(guān)系中，子用例是父用例的一種特殊形式，子用例繼承了父用例所有的結(jié)構(gòu)、行為和關(guān)系。但在實際應(yīng)用中很少使用泛化關(guān)系。UML中，用例之間的泛化關(guān)系用三角形箭頭表示，由子用例指向父用例。9/26/2023544.7用例間的關(guān)系泛化（generalization）關(guān)系4.7用例間的關(guān)系例如：執(zhí)行交易是一種交易抽象，執(zhí)行房產(chǎn)交易和執(zhí)行證券交易都是一種特殊的交易形式。用例“交易”與“房產(chǎn)交易”、“證券交易”之間就可以表示為泛化關(guān)系。9/26/2023554.7用例間的關(guān)系例如：執(zhí)行交易是一種交易抽象，執(zhí)行房產(chǎn)交4.8用例描述用例已經(jīng)確定下來，但是用例只是一個簡單的“動-賓”詞語，只知其意，不知其深意。如客戶服務(wù)人員的用例：查詢經(jīng)驗庫信息。通過此用例我們可以知道基本的業(yè)務(wù)過程是查詢經(jīng)驗信息，但是并不知道到底按照什么方式查，查些什么信息出來。在這種情況下，系統(tǒng)設(shè)計人員無法很好地開展工作。這樣就意味著我們必須詳細(xì)的描述用例。9/26/2023564.8用例描述用例已經(jīng)確定下來，但是用例只是一個簡單的“動4.8用例描述用例的描述應(yīng)該包含哪些內(nèi)容，并沒有一個統(tǒng)一的標(biāo)準(zhǔn)，不同的開發(fā)機(jī)構(gòu)可能會有不同的要求，但一般應(yīng)包含以下內(nèi)容：9/26/2023574.8用例描述用例的描述應(yīng)該包含哪些內(nèi)容，并沒有一個統(tǒng)一的4.8用例描述(1)用例的目標(biāo)是什么？(2)用例是怎么啟動的？(3)參與者和用例之間的消息是如何傳送的？(4)用例中除了主路徑外，其他路徑是什么？(5)用例結(jié)束后的系統(tǒng)狀態(tài)是怎樣的？(6)其他需要描述的內(nèi)容是什么？總之，描述用例的基本原則是盡可能寫得“詳細(xì)”、“充分”。9/26/2023584.8用例描述(1)用例的目標(biāo)是什么？8/8/202354.8用例描述作為OOA文檔的一個組成部分，用例的描述應(yīng)該有一定的規(guī)范格式，但沒有統(tǒng)一標(biāo)準(zhǔn)。然而，一個開發(fā)機(jī)構(gòu)內(nèi)部應(yīng)該采用統(tǒng)一的格式。后面是按照一個業(yè)界比較認(rèn)同的格式來描述客戶服務(wù)系統(tǒng)中的“維護(hù)客戶資料”用例。9/26/2023594.8用例描述作為OOA文檔的一個組成部分，用例的描述應(yīng)該4.8用例描述1.UC1：維護(hù)客戶資料1.1簡要說明該用例提供客戶服務(wù)人員對公司客戶資料進(jìn)行錄入、修改和刪除功能；Actor（角色）：客戶服務(wù)人員；2.事件流2.1基本流1、Actor選擇“維護(hù)客戶資料”功能啟動該用例；2、系統(tǒng)顯示維護(hù)客戶資料的主界面，其中列出查詢界面；3、Actor選擇新增客戶資料；4、系統(tǒng)提示錄入客戶資料；5、Actor輸入客戶編號、來源（售后、培訓(xùn)、電話咨詢、關(guān)系客戶）、類型（代理商、終端客戶、關(guān)系客戶）、省份、公司名稱、聯(lián)系人，聯(lián)系電話、EMAIL、登記時間、地址、郵編等。輸入完成后提交這些信息；6、系統(tǒng)驗證輸入數(shù)據(jù)是否正確；如驗證不正確則提示用戶重輸入；如檢驗正確則增加這個客戶信息，并返回到客戶資料維護(hù)主界面；7、Actor選擇‘退出’，該用例結(jié)束。9/26/2023604.8用例描述1.UC1：維護(hù)客戶資料8/8/202364.8用例描述2.2備選流2.2.1修改客戶資料1、在客戶資料維護(hù)的主界面，用戶選擇查詢某客戶資料；2、系統(tǒng)顯示符合條件的客戶資料，內(nèi)容包括；客戶編號、來源、類型、省份、公司名稱；3、Actor選擇修改某客戶資料；4、系統(tǒng)顯示修改客戶資料界面；5、Actor修改來源（售后、培訓(xùn)、電話咨詢、關(guān)系客戶）、類型（代理商、終端客戶、關(guān)系客戶）、省份、公司名稱、聯(lián)系人，聯(lián)系電話、EMAIL、地址、郵編、備注。并提交這些信息；6、系統(tǒng)驗證輸入數(shù)據(jù)是否正確（與基本流一致）；如檢驗不正確則提示用戶重輸入；如驗證正確則修改這個客戶信息，并返回到客戶資料維護(hù)主界面。2.2.1.1取消修改客戶資料1、在修改客戶資料界面中，用戶選擇‘取消’；2、系統(tǒng)返回到客戶資料維護(hù)主界面。9/26/2023614.8用例描述2.2備選流8/8/2023614.8用例描述2.2.2刪除客戶資料1、在客戶資料維護(hù)主界面的客戶資料顯示部分，用戶選擇“刪除”某客戶資料；2、系統(tǒng)提示用戶確認(rèn)刪除；3、用戶選擇‘確認(rèn)’；4、系統(tǒng)刪除所選客戶資料，并返回客戶資料維護(hù)主界面。2.2.2.1取消刪除客戶資料1、在提示用戶確認(rèn)刪除的界面中，用戶選擇‘取消’；2、系統(tǒng)返回到客戶資料維護(hù)主界面。3.特殊需求[無]4.前置條件客戶服務(wù)人員已經(jīng)登錄系統(tǒng)5.后置條件系統(tǒng)中保存了用戶所輸入的客戶資料。6.擴(kuò)展點(diǎn)[無]9/26/2023624.8用例描述2.2.2刪除客戶資料8/8/2023624.8用例描述以上內(nèi)容是參考了一些開發(fā)機(jī)構(gòu)和UML使用者的經(jīng)驗后總結(jié)出來的用例描述格式，形式如表4-2所示：（具體使用時可用表格的形式表示，也可以不使用表格形式）

9/26/2023634.8用例描述以上內(nèi)容是參考了一些開發(fā)機(jī)構(gòu)和UML使用者的4.8用例描述表4-2用例描述格式描述項說明用例名稱表明用戶的意圖或用例的用途，如“查詢客戶資料”用例編號【可選】唯一標(biāo)識符，在文檔其他地方可以通過標(biāo)識符來引用該用例用例描述簡要概述用例參與者與此用例相關(guān)的參與者優(yōu)先級【可選】一個有序的排列，1代表優(yōu)先級最高狀態(tài)【可選】用例的狀態(tài)，通常為以下幾種之一：進(jìn)行中、等待審批、通過審查或未通過審查前置條件一個條件列表，這些條件必須在訪問該用例前被滿足后置條件一個條件列表，這些條件必須在完成該用例后被滿足基本操作流程描述用例中各項工作都正常進(jìn)行時用例的工作方式備選操作流程描述變更工作方式、出現(xiàn)異?；虬l(fā)生錯誤時所遵循的路徑被泛化的用例【可選】此用例所泛化的用例列表被包含的用例【可選】此用例所包含的用例列表被擴(kuò)展的用例【可選】此用例擴(kuò)展點(diǎn)用例列表9/26/2023644.8用例描述表4-2用例描述格式描述項說明用例名稱4.8用例描述用例描述雖然看起來簡單，但事實上它是捕獲用戶需求的關(guān)鍵一步，很多人雖然也能給出用例的描述，但描述中往往存在很多錯誤或不恰當(dāng)?shù)牡胤?，在描述用例時容易犯的錯誤包括：9/26/2023654.8用例描述用例描述雖然看起來簡單，但事實上它是捕獲用戶4.8用例描述(1)只描述參與者的行為，沒有描述系統(tǒng)的行為。例如：1．取款1.1簡要說明客戶取款；2．事件流2.1基本流1、儲戶插入ATM卡，并鍵入密碼；2、儲戶按“取款”按鈕，并鍵入取款數(shù)目；3、儲戶取走現(xiàn)金、ATM卡以及收據(jù)；4、儲戶離開。9/26/2023664.8用例描述(1)只描述參與者的行為，沒有描述系統(tǒng)的行4.8用例描述(2)只描述系統(tǒng)的行為，沒有描述參與者的行為。例如：1．取款1.1簡要說明客戶取款；2．事件流2.1基本流1、ATM系統(tǒng)獲得ATM卡和密碼；2、設(shè)置事務(wù)類型為“取款”；3、ATM系統(tǒng)獲取要提取的現(xiàn)金數(shù)目；4、驗證賬戶上是否有足夠儲蓄金額；5、輸出現(xiàn)金、數(shù)據(jù)和ATM卡；6、系統(tǒng)復(fù)位。9/26/2023674.8用例描述(2)只描述系統(tǒng)的行為，沒有描述參與者的行4.8用例描述以上兩個錯誤原因是沒有理解用例描述的作用，即描述參與者與系統(tǒng)的交互過程。既然是交互過程那就是有來有往，“用戶做什么”然后“系統(tǒng)做什么”這兩樣應(yīng)該是成對出現(xiàn)在描述中。9/26/2023684.8用例描述以上兩個錯誤原因是沒有理解用例描述的作用，即4.8用例描述（3）描述過于冗長。例如：2．事件流2.2備選流2.2.1修改客戶資料1、在客戶資料維護(hù)的主界面，用戶選擇查詢某客戶資料；2、系統(tǒng)顯示符合條件的客戶資料，內(nèi)容包括；客戶編號、來源、類型、省份、公司名稱，同時在每行的開始位置放置“修改”的按鈕，以便讓用戶點(diǎn)擊進(jìn)行資料修改；3、用戶選擇某客戶記錄左邊的“修改”按鈕，修改某客戶資料；4、系統(tǒng)打開修改客戶資料界面；5、……9/26/2023694.8用例描述（3）描述過于冗長。例如：2．事件流8/8/4.8用例描述（4）描述的內(nèi)容不夠明確。例如：2.2備選流2.2.1修改客戶資料1、在客戶資料維護(hù)的主界面，用戶選擇查詢某客戶資料；2、系統(tǒng)顯示符合條件的客戶資料；3、用戶選擇修改某客戶資料；4、系統(tǒng)打開修改客戶資料界面；5、用戶修改來源（售后、培訓(xùn)、電話咨詢、關(guān)系客戶）、類型（代理商、終端客戶、關(guān)系客戶）、省份、公司名稱、聯(lián)系人，聯(lián)系電話、EMAIL、地址、郵編、備注。并選擇“提交”；6、系統(tǒng)檢查輸入數(shù)據(jù)是否正確；如檢驗不正確則提示用戶重新輸入；如檢驗正確則修改這個客戶信息，并返回到客戶資料維護(hù)主界面。9/26/2023704.8用例描述（4）描述的內(nèi)容不夠明確。例如：2.2備選流4.8用例描述在該