第三章用例圖

第3章用例圖東北大學(xué)信息科學(xué)與工程學(xué)院楊雷E-Mail:yanglei@1/336學(xué)習(xí)目標(biāo)1、掌握用例模型包括內(nèi)容2、熟練掌握用例圖3、熟練掌握用例圖中的關(guān)系4、掌握用例描述5、掌握用例圖建模技術(shù)2主要內(nèi)容3.1用例模型概述3.2用例圖3.3用例圖中的關(guān)系3.4用例描述3.5用例圖建模技術(shù)3用例模型概述用例模型：能夠有效地幫助開發(fā)人員發(fā)現(xiàn)真正的需求，并以適于用戶、客戶和開發(fā)人員的方法加以表示。用例模型包括：用于描述一個系統(tǒng)的所有用例圖和用例描述。用例模型特點：1）用例模型描述了待開發(fā)系統(tǒng)的功能需求。2）用例模型將系統(tǒng)看作黑盒。3）用例模型驅(qū)動了需求分析之后各階段的開發(fā)工作。4開發(fā)過程5UseCase驅(qū)動實現(xiàn)測試需求分析和設(shè)計UseCases把所有這些過程綁到一起在這些開發(fā)過程中，開發(fā)人員首先捕獲客戶的需求，并以用例的形式組織成用例模型。然后分析并設(shè)計系統(tǒng)來滿足這些用例，因此在用例模型之后就是分析模型，接著是設(shè)計模型和實施模型。在實現(xiàn)了整個系統(tǒng)之后，還將根據(jù)用例模型設(shè)計出測試模型來對系統(tǒng)進(jìn)行驗證這些模型之間并不是線性轉(zhuǎn)變的，它們是一個迭代、增量的開發(fā)過程。6主要內(nèi)容3.1用例模型概述3.2用例圖3.3用例圖中的關(guān)系3.4用例描述3.5用例圖建模技術(shù)7用例圖用例圖定義描述系統(tǒng)外部的執(zhí)行者與系統(tǒng)提供的用例之間的某種聯(lián)系。用例圖描述了一組用例、參與者以及它們之間的關(guān)系用例圖包含3個建模元素：（1）用例（2）參與者（角色）（3）關(guān)系8UseCase(用例，用例)UseCase概念是IvarJacobson于60年代和70年代在愛立信公司開發(fā)AKE，AXE系列系統(tǒng)時發(fā)明的，并在其博士論文(85年)和92年出版的論著中做了詳細(xì)論述[1]。在軟件開發(fā)中采用UseCase驅(qū)動是I.Jacobson對軟件界最重要的貢獻(xiàn)之一。自I.Jacobson的著作出版后，面向?qū)ο箢I(lǐng)域已廣泛接納了用例這一概念，并認(rèn)為它是第二代面向?qū)ο蠹夹g(shù)的標(biāo)志。[1]I.Jacobson，Object-orientedsoftwareengineering:ausecasedrivenapproach，Addison-Wesley,19929一個用例是外部參與者與系統(tǒng)之間的一系列典型交互過程，每個用例為參與者提供有價值的功能。例：在字處理程序中，“將正文置為黑體”是一個usecase；“創(chuàng)建索引”也是一個usecase。UseCase的定義10UseCase的定義在一個workshop(專題討論會)上，14位主要的OO專家對UseCase有14個定義。定義1：usecase是對一個活動者(actor)使用系統(tǒng)的一項功能時所進(jìn)行的交互過程的一個文字描述序列

(見[2])。定義2：用例是系統(tǒng)、子系統(tǒng)或類和外部的參與者(actor)交互的動作序列的說明，包括可選的動作序列和會出現(xiàn)異常的動作序列.(見[3])[2]

邵維忠，楊芙清，面向?qū)ο蟮南到y(tǒng)分析，p153[3]J.Rumbaugh,etc.TheUnifiedModelingLanguageReferenceManual,p48811Usecase從使用系統(tǒng)的角度描述系統(tǒng)中的信息，即站在系統(tǒng)外部察看系統(tǒng)功能，并不考慮系統(tǒng)內(nèi)部對該功能的具體實現(xiàn)方式。UseCase絕不是錦上添花的東西，一方面它可以促進(jìn)與用戶溝通，理解正確的需求，另一方面它可以劃分系統(tǒng)與外部實體的界限，是系統(tǒng)設(shè)計的起點，而最終應(yīng)該落實到類和實現(xiàn)代碼上。UseCase是對系統(tǒng)行為的動態(tài)描述，它是OO設(shè)計的起點，是類、對象、操作的來源，而通過邏輯視圖的設(shè)計，可以獲得軟件的靜態(tài)結(jié)構(gòu)。UseCase的說明12用例基本思想問題的提出：在系統(tǒng)尚未存在時，如何描繪用戶需要一個什么樣的系統(tǒng)？如何規(guī)范地定義用戶需求？考慮問題的思路：把系統(tǒng)看作一個黑箱，看它對外部的客觀世界發(fā)揮什么作用，描述它外部可見的行為。13Usecase是對系統(tǒng)行為的動態(tài)描述，屬于UML的動態(tài)建模部分。UML的靜態(tài)建模機(jī)制包括類圖(classdiagram)、對象圖(objectdiagram)、包(package)、構(gòu)件圖(componentdiagram)和配置圖(deploymentdiagram)。UML的動態(tài)建模機(jī)制包括用例圖(usecasediagram)，順序圖(sequencediagram)，協(xié)作圖(collaborationdiagram)，狀態(tài)圖(statechartdiagram)，活動圖(activitydiagram)。14用例的一些特點：（1）用例描述了用戶提出的一些可見的需求；（2）用例可大可??；（3）用例對應(yīng)一個具體的用戶目標(biāo)。理論上我們可以把一個軟件系統(tǒng)的所有UseCase畫出來，但實際運用時只需把重要的、交互過程復(fù)雜的那些畫出來。需求有兩種基本形式：功能性和非功能性的。不是所有的需求都要用usecase表示出來。問題：一個系統(tǒng)的需求包括哪些內(nèi)容？可以參照需求大綱UseCase的一些特點15AlistairCockburn提出的供參考用的需求大綱：Chapter1.Purposeandscope1a.Whatistheoverallscopeandgoal?1b.Stakeholders(whocares?)1c.Whatisinscope,whatisoutofscopeChapter2.Termsused/GlossaryChapter3.Theusecases3a.Theprimaryactorsandtheirgeneralgoals3b.Thebusinessusecases(operationsconcepts)3c.ThesystemusecasesChapter4.Thetechnologytobeused4a.Whattechnologyrequirementsarethereforthissystem?4b.Whatsystemswillthissysteminterfacewith,withwhatrequirements?16Chapter5.Othervariousrequirements5a.DevelopmentprocessQ1.Whoaretheprojectparticipants?Q2.Whatvalueswillbereflected(simple,soon,fast,orflexible)?Q3.Whatfeedbackorprojectvisibilitydotheusersandsponsorswant?Q4.Whatcanwebuy,whatmustwebuild,whatisourcompetition?Q5.Whatotherprocessrequirementsarethere(testing,installation,etc.)?Q6.Whatdependenciesdoestheprojectoperateunder?5b.Businessrules5c.Performance5d.Operations,security,documentation175e.Useandusability5f.Maintenanceandportability5g.UnresolvedordeferredChapter6.Humanbackup,legal,political,organizationalissuesQ1.Whatisthehumanbackuptosystemoperation?Q2.Whatlegal,whatpoliticalrequirementsarethere?Q3.Whatarethehumanconsequencesofcompletingthissystem?Q4.Whatarethetrainingrequirements?Q5.Whatassumptions,dependenciesarethereonthehumanenvironment?18爭論：本質(zhì)上，UseCase分析是一種功能分解(functionaldecomposition)的技術(shù)，沒有以對象觀點為中心，因而有人認(rèn)為UseCase分析只是OOA/OOD的先導(dǎo)性工作，并非OOA/OOD過程的一部分；但也有人視其為OOA/OOD的一環(huán)。不管怎樣，UseCase是UML的一部份，UseCase是OO開發(fā)過程中的第一步。19UseCase技術(shù)很容易使用，但也很容易誤用。正確使用UseCase技術(shù)來做好DomainModeling，以確保定義出正確的需求(rightrequirements)，然后開發(fā)出正確的系統(tǒng)(rightsystem)，是保證OO軟件開發(fā)成功的基礎(chǔ)。20collaborationUseCase是與實現(xiàn)無關(guān)(implementation-independent)的關(guān)于系統(tǒng)功能的描述。在UML中，用協(xié)作(collaboration)來指明對usecase的實現(xiàn)。usecaserealization例：UseCase的實現(xiàn)21尋找用例的方法用例定義3：用例是系統(tǒng)執(zhí)行的一系列的動作，這些動作將生成參與者可觀測的結(jié)果值。一個用例定義一組用例實例。用例要點可觀測：用例止于系統(tǒng)邊界結(jié)果值：用例是目標(biāo)向?qū)У南到y(tǒng)執(zhí)行：結(jié)果值是由系統(tǒng)生成的由參與者觀測：業(yè)務(wù)語言，用戶觀點一組用例實例：用例的粒度22可觀測描述交互，而不是內(nèi)在的系統(tǒng)活動23用例是目標(biāo)導(dǎo)向的系統(tǒng)的存在是因為：參與者有一些需要使用它來滿足的目標(biāo)。用例是用來描述系統(tǒng)的目標(biāo)24結(jié)果值由系統(tǒng)生成25業(yè)務(wù)語言而非技術(shù)語言26用戶觀點而非系統(tǒng)觀點27用例vs.功能28用例命名：參與者視角(狀語+)動詞+(定語+)賓語29用例粒度粒度過細(xì)，陷入功能分解。過細(xì)的粒度，一般都會導(dǎo)致技術(shù)語言的描述，而不再是業(yè)務(wù)語言。Jacobson說，對一個十人年的項目，他需要二十個用例。而在一個相同規(guī)模的項目中，MartinFowler*則用了一百多個用例。經(jīng)驗問題30確定用例的常見問題312.假設(shè)有這樣需求：學(xué)生檔案管理中，用戶經(jīng)常需要做三件事：增加一條學(xué)生記錄、修改一條學(xué)生記錄，刪除一條學(xué)生記錄。如果要畫出usecase圖，以下2種方法哪種更合適？方法1：再分成3個腳本，分別畫3個交互圖。腳本1增加學(xué)生記錄；腳本2修改學(xué)生記錄；腳本3刪除學(xué)生記錄。方法2：每個usecase畫一個交互圖。32Create,Retrieve,Update,Delete類型用例的處理：采用CRUD四個用例還是一個用例?從用戶需求的角度考慮而不是從數(shù)據(jù)處理的角度考慮。例:

?33Actor(參與者/角色)

定義1：Actor是指系統(tǒng)以外的，需要使用系統(tǒng)或與系統(tǒng)交互的東西，包括人，設(shè)備和其它系統(tǒng)。定義2：透過系統(tǒng)邊界與系統(tǒng)進(jìn)行有意義交互的任何事物。

.34識別系統(tǒng)邊界和參與者識別系統(tǒng)邊界某企業(yè)要求開發(fā)一個企業(yè)管理系統(tǒng)，并與原來已有的財會管理系統(tǒng)相連某企業(yè)要求開發(fā)一個企業(yè)管理系統(tǒng)，并把原來已有的財會管理系統(tǒng)加以改造，成為企業(yè)管理系統(tǒng)的一部分35例：在線銀行系統(tǒng)的一些可能的參與者：客戶：從系統(tǒng)獲取信息并執(zhí)行金融交易。管理人員：開辦系統(tǒng)的用戶。獲取并更新信息。廠商：接受作為轉(zhuǎn)帳支付結(jié)果的資金mail系統(tǒng)36actor說明：Actor不是指人，而是指代表某一種特定功能的角色，因此同一個人可能對應(yīng)很多個Actor。Actor是虛擬的概念，可以指人，外部系統(tǒng)，設(shè)備等。參與者代表在系統(tǒng)邊界之外的真實事物，并不是系統(tǒng)的一部分。參與者透過系統(tǒng)邊界與系統(tǒng)交互，參與者的確定代表著系統(tǒng)邊界的確定。交互是有意義的。一個actor可以執(zhí)行多個usecase；一個usecase也可以由多個actor所使用。37Actor實際上是一個版型化的類，其版型(Stereotype)是actor?？梢杂脦в邪嫘汀?lt;<actor>>”的類圖標(biāo)表示，也可以用人形圖標(biāo)表示。一般用類圖標(biāo)表示參與者是外部系統(tǒng)，用人形圖標(biāo)表示參與者是人。Icon形式Label形式Decoration形式38Actor與用例間的聯(lián)系 Actor可以與系統(tǒng)進(jìn)行包括收發(fā)消息在內(nèi)的交互，Actro是啟動用例的前提條件。Actor與用例之間是關(guān)聯(lián)關(guān)系。按照執(zhí)行者是否可以初始化用例分為主動參與者-客戶被動參與者-mail系統(tǒng)39Actor的泛化關(guān)系參與者(actor)之間可以存在泛化(generalization)關(guān)系，表示一個一般性的參與者與另一個更為特殊的參與者之間的聯(lián)系。如下圖所示：actorgeneralizationactor40練習(xí)某企業(yè)要求開發(fā)一個企業(yè)信息管理系統(tǒng)，并與原來已有的財會系統(tǒng)相連接。Actors？某企業(yè)要求開發(fā)一個企業(yè)信息管理系統(tǒng)，并把原來已有的財會系統(tǒng)加以改造，成為企業(yè)管理信息系統(tǒng)的一部分。Actors？41練習(xí)客戶給銷售員發(fā)來傳真訂貨，銷售員下班前將當(dāng)日訂貨單匯總輸入系統(tǒng)。Actors？尋呼臺系統(tǒng)。用戶如果預(yù)定了天氣預(yù)報，系統(tǒng)每天定時給他發(fā)天氣消息；如果當(dāng)天氣溫高于35度，還要提醒用戶注意防暑。Actors?42怎樣識別活動者誰向系統(tǒng)提供信息誰從系統(tǒng)獲取(使用)信息？誰操作系統(tǒng)？誰維護(hù)系統(tǒng)？系統(tǒng)使用哪些外部資源？系統(tǒng)是否和已經(jīng)存在的系統(tǒng)交互？是否事情自動在預(yù)期的時間發(fā)生？43Scenario(情景)用例是“由系統(tǒng)所執(zhí)行的一系列操作，其結(jié)果會對特定的操作者產(chǎn)生可觀察的結(jié)果”。用例所描述的參與者與系統(tǒng)交互的過程可以用一系列步驟來描述，這些步驟構(gòu)成一個場景（Scenario），場景的集合就是用例。44Scenario(情景)腳本(scenario)：也稱腳本，場景，情節(jié)，劇本等。在UML中，scenario指貫穿usecase的一條單一路徑，用來顯示usecase中某種特殊情況。例：在“訂貨”這個用例中，包含著幾個相關(guān)的scenario：一個是關(guān)于進(jìn)行順利的scenario；一個是有關(guān)貨源不足的scenario；一個是涉及客戶的信用卡被拒的scenario等等。這些scenario的組合構(gòu)成了一個用例。45scenario說明：一個scenario是一個usecase的實例(instance)scenario對于usecase相當(dāng)于object對于class。每個usecase都有一系列的scenarios一個主要的scenarioAlliswell次要的scenarios對于主要的scenario來說是例外或可以選擇的46主要內(nèi)容3.1用例模型概述3.2用例圖3.3用例圖中的關(guān)系3.4用例描述3.5用例圖建模技術(shù)47UseCase間的關(guān)系UseCase除了和參與者有關(guān)聯(lián)(association)外，UseCase之間也存在著一定的關(guān)系(relationship)。包括：泛化：同一業(yè)務(wù)目的不同技術(shù)實現(xiàn)包含：提取公共交互，提高復(fù)用擴(kuò)展：“凍結(jié)”基用例以保持穩(wěn)定。也可以利用UML的擴(kuò)充機(jī)制自定義UseCase間的關(guān)系。48泛化(generalization)關(guān)系泛化(generalization)代表一般與特殊的關(guān)系。usecase間的泛化關(guān)系與類之間的泛化關(guān)系（繼承關(guān)系）類似。說明泛化關(guān)系中，子用例繼承了父用例的行為和含義，子用例也可以增加新的行為和含義或覆蓋父用例中的行為和含義子用例可以替換父用例49parentusecasechildusecase驗證口令的用例行為:1.從數(shù)據(jù)庫中取得用戶口令2.要求用戶提供口令3.用戶輸入口令4.對用戶口令進(jìn)行驗證視網(wǎng)膜掃描的用例行為：1.從數(shù)據(jù)庫中獲取用戶視網(wǎng)膜信息2.掃描用戶的視網(wǎng)膜3.二者進(jìn)行比對驗證泛化關(guān)系的例子：50包含(include)關(guān)系包含(Include)關(guān)系是指一個用例可以簡單地包含其他用例具有的行為，并把它所包含的用例行為作為自身行為的一部分。被包含的用例不是孤立存在的，它僅作為某些包含它的更大的基用例的一部分出現(xiàn)。在包含關(guān)系中，在執(zhí)行基本用例時，一定執(zhí)行包含用例部分。包含關(guān)系是依賴關(guān)系的版型。51包含關(guān)系的事件流執(zhí)行順序52在兩種情況下引入包含關(guān)系：(a)如果兩個以上的用例有大量相同的功能，則可以將這個功能分解到另一個用例中。其他用例可以和這個用例建立包含關(guān)系。(公共的事件流提取出來)(b)一個用例的功能太多時,可以用包含關(guān)系建模兩個小用例。53包含關(guān)系的例子：54擴(kuò)展(extend)關(guān)系擴(kuò)展(extend)關(guān)系的基本含義與泛化關(guān)系類似，但是對于擴(kuò)展UseCase有更多的規(guī)則限制，即基本的UseCase必須聲明若干“擴(kuò)展點”(extensionpoint)，而擴(kuò)展UseCase只能在這些擴(kuò)展點上增加新的行為?；美强梢元毩⒂跀U(kuò)展用例存在的，只是在特定的條件下，它的行為可以被另一個用例的行為所擴(kuò)展。55擴(kuò)展關(guān)系的例子56圖書管理系統(tǒng)部分用例圖57練習(xí)請畫出學(xué)生成績管理系統(tǒng)的部分用例圖?參與者:學(xué)生用例:(1)上課(2)完成作業(yè)(3)參加考試(4)補(bǔ)考5859擴(kuò)展關(guān)系和包含關(guān)系的例子（1）baseusecase(對擴(kuò)展關(guān)系)extensionusecase(對擴(kuò)展關(guān)系)inclusionusecase(對包含關(guān)系)baseusecase(對包含關(guān)系)60練習(xí)請畫出圖書管理系統(tǒng)用例圖?參與者:讀者用例:(1)借書(2)查找書目(3)身份驗證注意：借書時必須進(jìn)行身份驗證，讀者只有在不知道要借圖書的名稱和編號的情況下查找書目。6162UseCase的泛化、擴(kuò)展、包含關(guān)系的比較一般------特殊的關(guān)系使用泛化關(guān)系。在包含關(guān)系中，在執(zhí)行基用例時，一定會執(zhí)行包含用例部分?；美强梢元毩⒂跀U(kuò)展用例存在的，只有在特定條件下，擴(kuò)展用例的行為才被執(zhí)行。一個基用例執(zhí)行時，可以執(zhí)行、也可以不執(zhí)行擴(kuò)展用例。63小結(jié)：actor，usecase的關(guān)系類型說明：使用用例間的關(guān)系不要畫的太復(fù)雜寧可不表現(xiàn)用例間的關(guān)系，也不要讓用例間的連線太多，造成視覺上的障礙。association關(guān)聯(lián):actor和usecase之間的關(guān)系包含:usecase之間的關(guān)系includeextend擴(kuò)展:usecase之間的關(guān)系generalization泛化:actor之間或usecase之間的關(guān)系關(guān)系類型說明表示符號64主要內(nèi)容3.1用例模型概述3.2用例圖3.3用例圖中的關(guān)系3.4用例描述3.5用例圖建模技術(shù)65UseCase的描述用例描述是關(guān)于角色與系統(tǒng)如何交互的規(guī)格說明要求清晰明確，沒有二義性；–在描述用例時，應(yīng)該只注重外部能力，不涉及內(nèi)部細(xì)節(jié)usecase采用自然語言描述參與者與系統(tǒng)進(jìn)行交互時雙方的行為，不追求形式化的語言表達(dá)。對UseCase的描述應(yīng)該包括：用例的目標(biāo);用例是如何啟動的;參與者和用例之間的消息是如何傳送的;用例中除了主路徑外，其他路徑是什么;用例結(jié)束后的系統(tǒng)狀態(tài);……描述用例時的原則：盡可能寫得“充分”，而不是追求寫得形式化，完整，漂亮。66UMLUserGuide中描述用例的方式：例：在ATM系統(tǒng)中，描述一個用例ValidateUser可以采用以下方式：主事件流：在系統(tǒng)提示顧客輸入PIN編號時，用例開始。顧客通過按鍵輸入PIN號。顧客按“輸入”按鈕確認(rèn)登錄。系統(tǒng)校驗這個PIN號是否有效。如果有效，系統(tǒng)承認(rèn)這次登錄，該用例結(jié)束。異常事件流：顧客可以在任何時間通過按“取消”按鈕取消一個事務(wù)，這樣，該用例重新開始。顧客的賬戶未發(fā)生改變。異常事件流：顧客可以在確認(rèn)之前的任何時刻消除PIN號，并重新輸入一個新的PIN號。異常事件流：如果顧客輸入了一個無效的PIN號，用例重新開始。如果連續(xù)3次無效，系統(tǒng)將取消整個事務(wù)，并在60秒內(nèi)阻止該顧客與ATM進(jìn)行交易。67作為OOA文檔的一個組成部分，UseCase的描述應(yīng)該有一定的規(guī)范格式。在統(tǒng)一的標(biāo)準(zhǔn)出現(xiàn)之前，人們可以創(chuàng)造發(fā)明usecase的不同表示形式，但至少在一個開發(fā)組織內(nèi)部應(yīng)該采用統(tǒng)一的格式。68用例名稱。表明用戶的意圖或usecase的用途，如“劃撥資金”。標(biāo)識符[可選]。唯一標(biāo)識符，如“UC1701”，在文檔的別處用標(biāo)識符來引用這個用例。用例描述。概述用例的幾句話。參與者。與此用例相關(guān)的參與者列表。優(yōu)先級。一個有序的排列，1代表優(yōu)先級最高。狀態(tài)[可選]。用例的狀態(tài)，通常為以下幾種之一：進(jìn)行中、等待審查、通過審查或未通過審查。用例的一個描述格式：(用例模板)69前置條件。一個條件列表，如果其中包含條件，則這些條件必須在訪問用例之前得到滿足。后置條件。一個條件列表，如果其中包含條件，則這些條件將在用例完成以后得到滿足?；静僮髁鞒?。描述用例中各項工作都正常進(jìn)行時用例的工作方式

?？蛇x操作流程。描述變更工作方式、出現(xiàn)異?；虬l(fā)生錯誤的情況下所遵循的路徑。被泛化的用例[可選]。此用例所泛化的用例列表。被包含的用例[可選]。此用例所包含的用例列表。被擴(kuò)展的用例[可選]。此用例所擴(kuò)展的用例列表。

70修改歷史記錄[可選]。關(guān)于用例的修改時間、修改原因和修改人的詳細(xì)信息。問題[可選]。與此用例的開發(fā)相關(guān)的問題的列表。決策[可選]。關(guān)鍵決策的列表，將這些決策記錄下來以便維護(hù)時使用。頻率[可選]。參與者訪問此usecase的頻率。如用戶每日訪問一次或每月一次。71用例名稱：處理訂單標(biāo)識符：UC1701用例描述：當(dāng)一個訂單初始化或者被查詢的時候這個用例開始。它處理有關(guān)訂單的初始化定義和授權(quán)等問題。當(dāng)訂單業(yè)務(wù)員完成了同一個顧客的對話的時候，它就結(jié)束了。參與者：訂單業(yè)務(wù)員優(yōu)先級：1狀態(tài)：通過審查前置條件：訂單業(yè)務(wù)員登錄進(jìn)系統(tǒng)后置條件：下訂單；庫存數(shù)目減少

例：用例模板72基本操作流程：1.顧客來訂購一個吉他，并且提供信用卡作為支付手段?！?.…..可選操作流程：顧客來訂購一個吉他，并且使用匯票的方式?！櫩蛠碛嗁徱粋€風(fēng)琴，并且提供信用卡作為支付手段?！櫩褪褂眯庞每ㄏ掠唵危菑埿庞每ㄊ菬o效的。顧客來下訂單，但他想要的商品沒有存貨。73被泛化的用例：無被包含的用例：無被擴(kuò)展的用例：無修改歷史記錄：張三,定義基本操作流程,2002/10/3張三,定義可選操作流程,2002/10/674練習(xí)請寫出學(xué)生選課系統(tǒng)中“登錄”用例的描述?75學(xué)生選課系統(tǒng)中“登錄”用例的描述用例名：登錄參與者：學(xué)生前置條件：進(jìn)入選課系統(tǒng)登錄界面。后置條件：登錄成功，進(jìn)入下一界面。76學(xué)生選課系統(tǒng)中“登錄”用例的描述基本操作流程：1）系統(tǒng)提示用戶輸入用戶名和密碼。2）用戶輸入用戶名和密碼。3）系統(tǒng)檢查用戶名和密碼的合法性。4）將檢查結(jié)果返回給用戶，進(jìn)入下一界面?？蛇x操作流程：3.a如果用戶名和密碼不合法，給出提示，結(jié)束。77用例描述的一些常見錯誤分析在描述用例時易犯的錯誤包括：只描述系統(tǒng)的行為，沒有描述actor的行為。只描述actor的行為，沒有描述系統(tǒng)的行為。設(shè)定對用戶界面的設(shè)計的要求。過于冗長。78UseCase:WithdrawCash（提取現(xiàn)金）參與者：Customer基本操作流程：1.儲戶插入ATM卡，并鍵入密碼。2.儲戶按“Withdrawal”按鈕，并鍵入取款數(shù)目。3.儲戶取走現(xiàn)金、ATM卡并拿走收據(jù)。4.儲戶離開。上述描述中存在的問題：只描述了參與者的動作序列，沒有描述系統(tǒng)的行為。改進(jìn)的描述如下：例1：下面是一個用例描述的片斷：79UseCase:WithdrawCash（提取現(xiàn)金）參與者:AccountHolder基本操作流程：1.通過讀卡機(jī)，儲戶插入ATM卡。2.ATM系統(tǒng)從卡上讀取銀行ID、帳號、加密密碼、并用主銀行系統(tǒng)驗證銀行ID和帳號。3.儲戶鍵入密碼，ATM系統(tǒng)根據(jù)上面讀出的卡上加密密碼，對密碼進(jìn)行驗證。4.儲戶按“FASTCASH”按鈕，并鍵入取款數(shù)量，取款數(shù)量應(yīng)該是5美元的倍數(shù)。5.ATM系統(tǒng)通知主銀行系統(tǒng)，傳遞儲戶帳號和取款數(shù)量，并接收返回的確認(rèn)信息和儲戶帳戶余額。6.ATM系統(tǒng)輸出現(xiàn)金，ATM卡和顯示帳戶余額的收據(jù)。7.ATM系統(tǒng)記錄事務(wù)到日志文件。例1（改進(jìn)的描述）80UseCase:WithdrawCash參與者:Customer基本操作流程：1.ATM系統(tǒng)獲得ATM卡和密碼。2.設(shè)置事務(wù)類型為"Withdrawal"3.ATM系統(tǒng)獲取要提取的現(xiàn)金數(shù)目。4.驗證帳戶上是否有足夠儲蓄金額。5.輸出現(xiàn)金，數(shù)據(jù)和ATM卡。6.系統(tǒng)復(fù)位。上述描述中存在的問題：只描述了ATM系統(tǒng)的行為，而沒有描述參與者的行為。這樣的描述很難理解，驗證和修改。改進(jìn)的描述同例1。例2：下面是一個用例描述的片斷：81UseCase:BuySomething參與者:Customer基本操作流程：1.系統(tǒng)顯示“IDandPassword”屏幕。2.顧客鍵入ID和密碼，然后按OK按鈕。3.系統(tǒng)驗證顧客ID和密碼，并顯示“PersonalInformation”屏幕4.顧客鍵入姓名、街道地址、城市、州、郵政編碼、電話號碼，然后按OK按鈕。5.系統(tǒng)驗證用戶是否為老顧客。6.系統(tǒng)顯示可以賣的商品列表。7.顧客在準(zhǔn)備購買的商品圖片上點擊，并在圖片旁邊輸入要購買的數(shù)量。選購商品完畢后按“Done”按鈕。8.系統(tǒng)通過庫存輔助系統(tǒng)驗證要購買的商品是否有足夠庫存。...etc.例3：下面是一個用例描述的片斷：82上述描述中存在的問題：對用戶界面的描述過于詳細(xì)，對于需求文檔來說，詳細(xì)的UI描述對獲取需求并無幫助。改進(jìn)的描述可以如下所示：83UseCase:BuySomething參與者:Customer基本操作流程：1.顧客使用ID和密碼進(jìn)入系統(tǒng)。2.系統(tǒng)驗證顧客身份。3.顧客提供姓名、地址、電話號碼。4.系統(tǒng)驗證顧客是否為老顧客。5.顧客選擇要購買的商品和數(shù)量。6.系統(tǒng)通過庫存輔助系統(tǒng)驗證要購買的商品是否有足夠庫存。...etc.84例4：下面是一個用例描述的片斷：UseCase:BuySomething參與者:user(或Customer)主事件流：1.顧客使用ID和密碼進(jìn)入系統(tǒng)。2.系統(tǒng)驗證顧客身份。3.顧客提供姓名。4.顧客提供地址。5.顧客提供電話號碼。6.顧客選取商品。7.顧客確定商品的數(shù)量。8.系統(tǒng)驗證顧客是否為老顧客。9.系統(tǒng)打開到庫存系統(tǒng)的連接。10.系統(tǒng)通過庫存系統(tǒng)請求當(dāng)前庫存量。11.庫存系統(tǒng)返回當(dāng)前庫存量12.系統(tǒng)驗證購買商品的數(shù)量是否小于庫存量。...etc.85UseCase:BuySomething參與者:user(或Customer)基本操作流程：1.顧客使用ID和密碼進(jìn)入系統(tǒng)。2.系統(tǒng)驗證顧客身份。3.顧客提供個人信息(包括姓名、地址、電話號碼),選擇要購買的商品及數(shù)量。4.系統(tǒng)驗證顧客是否為老顧客。5.系統(tǒng)使用庫存系統(tǒng)驗證要購買的商品數(shù)量是否少于庫存量。...etc.86主要內(nèi)容3.1用例模型概述3.2用例圖3.3用例圖中的關(guān)系3.4用例描述3.5用例圖建模技術(shù)873.5用例圖建模技術(shù)用例圖建模步驟：一、獲取用戶需求二、需求分析三、需求描述88一、獲取用戶需求（1）什么是用戶需求它主要是說明系統(tǒng)所必須符合的條件或者應(yīng)該具備的的功能，也即它用來描述系統(tǒng)應(yīng)該和不應(yīng)該做什么也即決定本系統(tǒng)應(yīng)該有什么功能，從而開發(fā)者和用戶可以創(chuàng)建一個初始的商業(yè)聯(lián)系。重點體現(xiàn)在應(yīng)該了解系統(tǒng)應(yīng)該做什么，而不是考慮如何做。需求最根本的挑戰(zhàn)在于：尋找、交流并記錄什么是真正需要的，并能夠向用戶和開發(fā)團(tuán)隊講解。一個關(guān)于影響項目進(jìn)展的因素的研究如下圖可見37%的問題都與需求有關(guān)，這就需要“需求開發(fā)”和“需求管理”。89（2）需求表達(dá)的形式。表達(dá)需求可以采用多種不同的方式，如可以用商業(yè)的概念、該領(lǐng)域的術(shù)語、框圖或者其它方法將功能性的需求寫成文檔（3）如何獲取用戶需求獲取用戶需求比較有效的方式是通過座談會、調(diào)查、訪談等形式，了解客戶方的所有要求以及潛在的要求，有時還需要在用戶方工作一定時間以深入了解其業(yè)務(wù)流程和潛在的業(yè)務(wù)規(guī)則。90（4）細(xì)分需求功能需求非功能需求（主要涉及系統(tǒng)性能、可用性、可管理性、可靠性、可擴(kuò)展性、安全性等等）環(huán)境限制設(shè)計約束等類型（比如開發(fā)的領(lǐng)導(dǎo)層或者用戶方堅持要使用Java開發(fā)）。91某餐館定座系統(tǒng)需求示例（1）功能性的需求服務(wù)生可以通過系統(tǒng)查詢是否有滿足條件的餐桌尚未定出服務(wù)生可以通過系統(tǒng)為顧客定座以及取消定座服務(wù)生可以查詢客戶以往的消費情況。（2）非功能性的需求系統(tǒng)的響應(yīng)查詢時間應(yīng)該小于10秒系統(tǒng)必須7X24小時服務(wù)，每天可以有30分鐘的維護(hù)時間，同時只能在0點到1點之間（3）環(huán)境限制 在局域網(wǎng)絡(luò)的環(huán)境中完成此功能。92二、需求分析確定系統(tǒng)范圍和邊界識別參與者、識別用例對用例進(jìn)行描述確定用例、參與者之間的關(guān)系構(gòu)造用例模型931、確定系統(tǒng)范圍和邊界系統(tǒng)范圍：指系統(tǒng)問題域的目標(biāo)、任務(wù)、規(guī)模及系統(tǒng)提供的功能和服務(wù)。系統(tǒng)邊界：指一個系統(tǒng)的所有系統(tǒng)元素與系統(tǒng)以外的事物的分界線。確定系統(tǒng)范圍和邊界：將系統(tǒng)內(nèi)部元素和系統(tǒng)外部事物劃分開。系統(tǒng)開發(fā)主要任務(wù)：對系統(tǒng)邊界內(nèi)的元素進(jìn)行分析、設(shè)計和實現(xiàn)，系統(tǒng)邊界外部的事物統(tǒng)稱為參與者。94識別參與者注意事項參與者主要是指角色而非具體的個人用戶與參與者的關(guān)系一個用戶可以抽象為多個參與者一個參與者可以包含多個用戶發(fā)現(xiàn)參與者對提供用例是非常有用。因為面對一個大系統(tǒng)，要列出用例清單常常是十分困難的。這時可以先列出參與者清單，在對每個參與者列出他們的用例，問題就會變得容易很多。95如何獲取系統(tǒng)參與者？獲取用例首先要找出系統(tǒng)的參與者。嚴(yán)格的識別系統(tǒng)是不可能的。在需求研討會上，我們可以通過“頭腦風(fēng)暴”來獲得主要參與者或者可以通過根據(jù)用戶回答的些問題答案來識別參與者。96從如下方面尋找參與者用戶從直接使用系統(tǒng)的人員中發(fā)現(xiàn)參與者。這里強(qiáng)調(diào)的是直接使用，而不是間接的。特定的人，在系統(tǒng)中可扮演不同的角色。例如，添加數(shù)據(jù)、使用數(shù)據(jù)及產(chǎn)生報告的那個人就扮演了三種不同的角色，反映為三種不同的參與者。例如，用戶角色的類別可為：目標(biāo)終端用戶、管理員、經(jīng)理或顧客。外部系統(tǒng)所有與系統(tǒng)交互的外部應(yīng)用系統(tǒng)都是參與者。從系統(tǒng)邊界的角度，應(yīng)該把與軟件系統(tǒng)一起運行以完成特定任務(wù)的應(yīng)用系統(tǒng)，看作是外部的應(yīng)用。相對于當(dāng)前在正在開發(fā)的系統(tǒng)而言，外部應(yīng)用系統(tǒng)可以是其他子系統(tǒng)、上級系統(tǒng)、下級系統(tǒng)或任何與它進(jìn)行協(xié)作的系統(tǒng)，但對它的開發(fā)并不是當(dāng)前系統(tǒng)的開發(fā)小組的責(zé)任。97設(shè)備識別所有與系統(tǒng)交互的設(shè)備。這樣的設(shè)備與系統(tǒng)相連，向系統(tǒng)提供外界信息，或在系統(tǒng)的控制下運行。通常，不包括監(jiān)視器、鍵盤、鼠標(biāo)和其它的標(biāo)準(zhǔn)的用戶接口類型設(shè)備，但我們考慮外部傳感器（輸入信息）和受控馬達(dá)（輸出信息）。外部事件？當(dāng)構(gòu)造實時和異步交互的系統(tǒng)時，將外部事件識別為潛在的參與者就變得更加重要了。例如，一種說法：由時間的流逝而激發(fā)系統(tǒng)的活動是常見的情況?？梢园褧r間事件作為一個參與者，也可以把時間事件作為系統(tǒng)的一部分，還可以把二者結(jié)合起來使用。98總結(jié)：如何發(fā)現(xiàn)參與者？人員——系統(tǒng)的直接使用者直接為系統(tǒng)服務(wù)的人員設(shè)備——與系統(tǒng)直接相聯(lián)的設(shè)備為系統(tǒng)提供信息在系統(tǒng)控制下運行不與系統(tǒng)相聯(lián)的設(shè)備×計算機(jī)設(shè)備×外系統(tǒng)——上級系統(tǒng)子系統(tǒng)其它系統(tǒng)外部事件?99舉例:一個簡化的學(xué)生選課系統(tǒng)，學(xué)生可以使用該系統(tǒng)選修課程。用戶需求說明:為每個使用系統(tǒng)的人員設(shè)置權(quán)限，只有通過權(quán)限驗證的人才能使用系統(tǒng)。

學(xué)生可以使用該系統(tǒng)查看課程信息、選修課程。

學(xué)生選課時，系統(tǒng)要通過財務(wù)管理系統(tǒng)核對學(xué)生是否交費，只有交費的學(xué)生才能選修課程。

系統(tǒng)錄入員負(fù)責(zé)錄入選修課程信息和教師信息。100學(xué)生選課系統(tǒng)的參與者101如何識別系統(tǒng)用例？參與者:“誰來做？”用例：“做什么？”通過以下幾個問題可以幫助識別用例：(1)參與者希望系統(tǒng)提供什么功能;(2)系統(tǒng)是否存儲、刪除和檢索信息，如果是這個行為由哪個參與者觸發(fā);(3)當(dāng)系統(tǒng)改變狀態(tài)時,通知參與者嗎;(4)存在影響系統(tǒng)的外部事件嗎;(5)是哪個參與者通知系統(tǒng)這些事件。102尋找用例的方法和用戶交互?；静呗裕喊炎约寒?dāng)作actor，與設(shè)想中的系統(tǒng)進(jìn)行交互?？紤]：系統(tǒng)交互的目的是什么？需要向系統(tǒng)輸入什么信息？希望由系統(tǒng)進(jìn)行什么處理并從它得到何種結(jié)果？確定UseCase和確定actor不能截然分開。103Jacobson提出以下問題：每個actor的主要任務(wù)是什么？該actor是否將讀、寫或修改系統(tǒng)的任何信息？actor是否該把系統(tǒng)外部的變化通知系統(tǒng)？actor是否希望系統(tǒng)把預(yù)料之外的變化通知自己？尋找用例時需要注意的問題：不要一開始就去捕捉所有的細(xì)節(jié)。全面地認(rèn)識和定義每一個usecase，要點是以窮舉的方式考慮每一個actor與系統(tǒng)的交互情況。104利用參與者捕獲用例對所有的參與者（把自己作為參與者），提問下列問題：每個參與者的主要任務(wù)是什么？為了達(dá)到某種目的，它們參加什么活動？該參與者是否將讀寫系統(tǒng)的任何信息？參與者是否該把系統(tǒng)外部的變化通知系統(tǒng)？參與者是否希望系統(tǒng)把預(yù)料之外的變化通知自己？在交互過程中，它們是怎樣使用系統(tǒng)的服務(wù)來完成它們的任務(wù)以達(dá)到目的？它們參加了什么在本質(zhì)上是不同的過程？是什么事件引起了與系統(tǒng)進(jìn)行交互的序列？105從系統(tǒng)功能角度捕獲用例用于本步驟的一些簡單的指導(dǎo)如下：一個用例描述一項功能，這項功能不能過大。例如，把一個企業(yè)信息管理系統(tǒng)粗略地分為生產(chǎn)管理、供銷管理、財務(wù)管理和人事管理等幾大方面的功能，就顯得粒度太大了，應(yīng)該再進(jìn)行細(xì)化。全面地認(rèn)識和定義每一個用例，要點是以窮舉的方式考慮每一個參與者與系統(tǒng)的交互情況，看看每個參與者要求系統(tǒng)提供什么功能，以及參與者的每一項輸入信息將要求系統(tǒng)作出什么反映，進(jìn)行什么處理。以窮舉的方式檢查用戶對系統(tǒng)的功能需求是否能在各個用例中體現(xiàn)出來。一個用例應(yīng)該是一個完整的任務(wù)，通常應(yīng)該在一個相對短的時間段內(nèi)完成。如果一個用例的各部分被分配在不同的時間段，尤其被不同的參與者執(zhí)行，最好還是將各部分作為單獨的用例對待。考慮對例外情況的處理。針對用例描述的基本流，要詳盡地考慮各種其他的情況106審查參與者確定系統(tǒng)環(huán)境中的所有角色，并都?xì)w入了相應(yīng)的參與者。每個參與者都至少和一個用例關(guān)聯(lián)；若一個參與者是另一個參與者的一部分，或扮演了類似的角色，考慮在它們之間使用泛化關(guān)系；用例每個用例都至少和一個參與者相關(guān)；若兩個用例有相同或相似的序列，可能需要合并它們，或抽取出一個新用例，在它們之間使用包含、擴(kuò)展或泛化關(guān)系。若用例過于復(fù)雜，為了易于理解，考慮進(jìn)行分解；若一個用例中有完全不同的事件流，最好把它分解成不同的用例107舉例:一個簡化的學(xué)生選課系統(tǒng)，學(xué)生可以使用該系統(tǒng)選修課程用戶需求說明:1.系統(tǒng)管理員為每個使用系統(tǒng)的人員設(shè)置權(quán)限，只有通過權(quán)限驗證的人才能使用系統(tǒng)。2.學(xué)生可以使用該系統(tǒng)查看課程信息、選修課程。3.學(xué)生選課時，系統(tǒng)要通過財務(wù)管理系統(tǒng)核對學(xué)生是否交費，只有交費的學(xué)生才能選修課程。4.系統(tǒng)錄入員負(fù)責(zé)錄入選修課程信息和教師信息。108學(xué)生選課系統(tǒng)的系統(tǒng)用例1093、對用例進(jìn)行描述用例名：選課參與者：學(xué)生前置條件：成功登錄，進(jìn)入選課界面。后置條件：退出選課界面?；臼录鳎?.瀏覽本學(xué)期預(yù)開設(shè)的課程。2.學(xué)生選擇要選修的課程并確認(rèn)。3.系統(tǒng)通過財務(wù)系統(tǒng)檢查學(xué)生是否交費。4.系統(tǒng)更新該學(xué)生所選課程。5.系統(tǒng)顯示學(xué)生所選課程。6.學(xué)生提交所選課程。7.系統(tǒng)保存學(xué)生所選課程。備選事件流：2.a如果學(xué)生沒有交費，給出提示，結(jié)束。5.a如果學(xué)生沒有提交，給出提示，結(jié)束。1104、確定用例、參與者之間的關(guān)系，構(gòu)造用例模型按照用例進(jìn)行分析，看一看每一個用例都和哪些參與者相關(guān)。111112三、需求描述用戶需求分析的結(jié)果需要用規(guī)范的文檔記錄下來，這就是用戶需求文檔。113需要注意以下幾點：在后續(xù)的開發(fā)過程中，很可能發(fā)現(xiàn)需求有了新的變化，或發(fā)現(xiàn)原先的理解有偏差，這時有必要修改已有的用例模型，以保證模型的正確性和一致性。不要把用例圖畫成工作流程圖。用例圖是描述系統(tǒng)功能的靜態(tài)圖?？梢杂没顒訄D描述工作流，作為相應(yīng)用例的補(bǔ)充。用例的大小要適中，原則是不但要捕獲需求還要便于實施后續(xù)的分析、設(shè)計與測試。若發(fā)現(xiàn)用例過大，就要進(jìn)一步考慮用例的細(xì)節(jié)。若發(fā)現(xiàn)用例過小，就要考慮這樣的用例是否為更大的用例的一個步驟。用例描述的是系統(tǒng)內(nèi)外交互的情況，但不能按人機(jī)界面來繪制用例圖，而應(yīng)該按功能來描述系統(tǒng)內(nèi)外的交互。注意，界面不是用例，用例也不是界面，一個用例可能包含所要建造的系統(tǒng)的多個界面，一個界面也可能由多個用例使用。在用用例描述需求的細(xì)節(jié)時，講的是系統(tǒng)做什么，而不是如何做。也就是說，僅描述系統(tǒng)內(nèi)外交互的情況，不應(yīng)該包含系統(tǒng)內(nèi)部的實現(xiàn)信息，否則會陷入分析癱瘓狀態(tài)，對實現(xiàn)細(xì)節(jié)糾纏不清。盡量不要使用多層的包含、擴(kuò)展或繼承關(guān)系，因為這樣做有可能要走上功能分解的道路。114例1、圖書管理系統(tǒng)的用例模型：一.獲取用戶需求：確定系統(tǒng)總體信息用戶需求描述:讀者：讀者借書讀者還書讀者預(yù)訂書籍讀者取消預(yù)訂讀者查詢書籍讀者查詢借閱信息續(xù)借注意：讀者預(yù)訂書籍、取消預(yù)訂和查詢借閱信息需要登錄系統(tǒng)。讀者借書和還書時需要通過圖書管理員完成。115圖書管理員：書籍歸還處理書籍借閱處理刪除書籍預(yù)留信息檢查用戶借閱合法性注意：書籍歸還處理時，如果超期或損壞則交納罰金。書籍借閱處理時，需要檢查用戶借閱的合法性，同時刪除書籍預(yù)訂信息。116分析整理：登錄查詢讀者信息查詢書目信息書籍歸還處理書籍借閱處理刪除書籍預(yù)留信息檢查用戶借閱合法性交納罰金117系統(tǒng)管理員：查詢讀者信息查詢書籍信息增加書目刪除或更新書目增加書籍刪除書籍添加借閱者帳戶刪除或更新借閱者帳戶信息118二.需求分析1、確定系統(tǒng)范圍和邊界：圖書的計算機(jī)管理系統(tǒng)2、確定系統(tǒng)參與者讀者（借閱者）圖書管理員系統(tǒng)管理員1193確定系統(tǒng)用例(1)讀者用例登錄讀者預(yù)訂書籍讀者取消預(yù)留書籍讀者查詢書籍信息讀者查詢借閱信息續(xù)借120圖書管理員處理借書、還書等的用例書籍歸還處理書籍借閱處理刪除書籍預(yù)留信息檢查用戶借閱合法性查詢讀者信息121系統(tǒng)管理員進(jìn)行系統(tǒng)維護(hù)的用例查詢讀者信息查詢書目信息增加書目刪除更新書目增加書籍刪除書籍添加借閱者刪除或更新借閱者1223.需求描述(1)用例圖(2)用例描述(略)123124125126127128實例很多軟件系統(tǒng)在一開始都需要登錄，若用戶登錄成功，則可進(jìn)入系統(tǒng)。如下以一個研究生學(xué)籍管理系統(tǒng)為例，描述四種登錄方法。為了簡化起見，假設(shè)此處僅描述登錄、選課和查看學(xué)分這3項功能。129方案1由于選課和查看學(xué)分都需要登錄，故專門設(shè)立一個“登錄”用例。若登錄成功，則可以進(jìn)行選課，也可以進(jìn)行查看學(xué)分如下為對用例“登錄”的描述研究生啟動系統(tǒng)；系統(tǒng)提示研究生輸入研究生證號和密碼；研究生輸入研究生證號和密碼；系統(tǒng)進(jìn)行驗證，給出驗證信息；若通過，若該生選擇選課系統(tǒng)執(zhí)行用例“選課”；若通過，若該生選擇查看學(xué)分系統(tǒng)執(zhí)行用例“查看學(xué)分”；該方法的缺點是，必須要了解系統(tǒng)的所有其它模塊，才能描述清楚“登錄”用例。向系統(tǒng)增加新用例時，也要修改登錄用例。此外，從維護(hù)的角度看，有時會忘記對“登錄”用例進(jìn)行修改130方案2讓所有的相關(guān)用例都包含登錄用例如下為對用例”選課”的描述研究生啟動系統(tǒng)，調(diào)用用況“登錄”若通過，系統(tǒng)執(zhí)行用況“選課”的其余部分；如下為對用例”查看學(xué)分”的描述；研究生啟動系統(tǒng)，調(diào)用用況“登錄”若通過，系統(tǒng)執(zhí)行用況“查看學(xué)分”的其余部分；這個方法中的“登錄”用況僅描述有關(guān)登錄的信息，研究生執(zhí)行系統(tǒng)的每項功能都要先登錄。其缺點為，對研究生要進(jìn)行多次驗證131方案3使用擴(kuò)展，設(shè)計系統(tǒng)登錄如下為對用例“登錄”的描述研究生啟動系統(tǒng)；系統(tǒng)提示研究生輸入研究生證號和密碼；研究生輸入研究生證號和密碼；系統(tǒng)進(jìn)行驗證，給出驗證信息；若通過，若該生選擇選課系統(tǒng)在擴(kuò)展點”選課”處執(zhí)行用況“選課”；若通過，若該生選擇查看學(xué)分系統(tǒng)在擴(kuò)展點”查看學(xué)分”處執(zhí)行用況“查看學(xué)分”；該方法與方法一相比，對“登錄”用況的描述要清楚一些。在增加新用況時，僅在登錄用況中添加擴(kuò)展點即可。132方案4登錄用況完全獨立于其它用況若使用該方法，必須要在“選課”用況和“查看學(xué)分”用況中指定前置條件：只有在登錄成功后才能執(zhí)行自己。如下為對用例”登陸”的描述研究生啟動系統(tǒng)；系統(tǒng)提示研究生輸入研究生證號和密碼；研究生輸入研究生證號和密碼；系統(tǒng)進(jìn)行驗證，給出驗證信息；如下為對用例”選課”的描述；若研究生通過了登錄且選擇了選課，系統(tǒng)開始執(zhí)行用況“選課”；……133