系統(tǒng)分析與設(shè)計(jì)ch02需求用例_第1頁
系統(tǒng)分析與設(shè)計(jì)ch02需求用例_第2頁
系統(tǒng)分析與設(shè)計(jì)ch02需求用例_第3頁
系統(tǒng)分析與設(shè)計(jì)ch02需求用例_第4頁
系統(tǒng)分析與設(shè)計(jì)ch02需求用例_第5頁
已閱讀5頁,還剩116頁未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡介

1需求&用例

--分析者必備浙江大學(xué)軟件學(xué)院程學(xué)林開發(fā)流程3圖6-1UP制品影響力示例面向?qū)ο笈c面向過程區(qū)別如果你的分析習(xí)慣是在調(diào)研需求時(shí)先弄清楚有多少業(yè)務(wù)流程,先畫出業(yè)務(wù)數(shù)據(jù)流程圖,然后順藤摸瓜,找業(yè)務(wù)流程中每一步驟的參與部門或崗位,弄清楚這一步參與者所做的事情和填寫表單的結(jié)果,并關(guān)心用戶是否如何把這份表單傳給到下一環(huán)節(jié)的。那么很不幸,你還在做面向過程的事情。如果你的分析習(xí)慣是在調(diào)研需求時(shí)最先弄清楚有多少個(gè)部門,多少崗位,然后找到每個(gè)崗位的業(yè)務(wù)代表,問他們類似的問題:你平時(shí)都做什么?這件事是誰交辦的?做完了你需要通知或傳達(dá)給誰嗎?做這件事情你都需要填寫些什么表格嗎?…那么恭喜你,你已經(jīng)OO拉!獲取用例的準(zhǔn)備工作議程需求定義用例及用例圖用例描述UP中如何使用用例分析者必學(xué)元素識別參與者識別用例編寫用例描述案例實(shí)踐與分析RequirementsFactorsonchallengedsoftwareprojects37%offactorsrelatedtoproblemswithrequirementsWaterfallModelActualuseofrequestedfeatures

Whatisrequirement?Requirementsarecapabilitiesandconditionstowhichthesystem(andmorebroadly,theproject)mustconform.[JBR99].TypesofRequirements

–FURPS+:Functional,features,capabilities,security.Usability,humanfactors,help,documentation.Reliability,frequencyoffailure,recoverability,predictability.Performance,responsetimes,throughput,accuracy,availability,resourceusage.Supportabilityadaptability,maintainability,internationalization,configurability.TypesofRequirements

–FURPS+The“+”inFURPS+indicatesancillary(輔助的)andsub-factors,suchas:Implementationresourcelimitations,languagesandtools,hardware,...Interfaceconstraintsimposedbyinterfacingwithexternalsystems.Operationssystemmanagementinitsoperationalsetting.PackagingLegallicensingandsoforth.HowareRequirementsOrganizedinUPArtifacts?Vision Ashortexecutiveoverviewdocumentforquicklylearningtheproject'sbigideas.Use-CaseModelfunctional(behavioral)requirements.SupplementarySpecificationallnon-functionalrequirements,suchasperformanceorlicensing.GlossaryBusinessRulesWhatareActors,Scenarios,andUseCases?Anactorissomethingwithbehavior,suchasaperson(identifiedbyrole),computersystem,ororganization;forexample,acashier.Ascenarioisaspecificsequenceofactionsandinteractionsbetweenactorsandthesystem;itisalsocalledausecaseinstance.Ausecaseisacollectionofrelatedsuccessandfailurescenariosthatdescribeanactorusingasystemtosupportagoal.ThreekindsofexternalactorsPrimary(主要)actorhasusergoalsfulfilledthroughusingservicesoftheSuD.Tofindusergoals,whichdrivetheusecases.Supporting(協(xié)助、支持)actorprovidesaservice(forexample,information)totheSuD.Toclarifyexternalinterfacesandprotocols.Offstage(幕后)actorhasaninterestinthebehavioroftheusecase,butisnotprimaryorsupporting;forexample,agovernmenttaxagency.場景(Scenario)特點(diǎn)是系統(tǒng)的一個(gè)特定情節(jié)或用例的一條執(zhí)行路徑是從用例中實(shí)例化出來的一組活動,一個(gè)用例可實(shí)例化出多個(gè)用例實(shí)例一個(gè)用例定義了一組用例實(shí)例,是對一組用例實(shí)例的抽象用例(UseCase)的定義站在用戶角度定義軟件系統(tǒng)的外部特征可表示系統(tǒng)所提供的服務(wù)或可執(zhí)行的某種行為用例是一種把現(xiàn)實(shí)世界的需求捕獲下來的方法。用例的概念在1986年由IvarJacobson正式提出之后被廣泛接受,迅速發(fā)展,已成為OO、UML、RUP的標(biāo)準(zhǔn)規(guī)范和方法。一組用例實(shí)例,其中每個(gè)實(shí)例都是系統(tǒng)執(zhí)行的一系列活動,這些活動產(chǎn)生了對某個(gè)參與者而言可觀察的結(jié)果。【RUP】一組用例實(shí)例一個(gè)用例由一組可產(chǎn)生某些特定結(jié)果的行為構(gòu)成,這些行為是不可再分解的(接收用戶輸入、執(zhí)行、產(chǎn)生結(jié)果)可觀測到的、有價(jià)值的結(jié)果(observableresultofvalue)用例必須對用戶產(chǎn)生價(jià)值;系統(tǒng)執(zhí)行(systemperforms)系統(tǒng)為外部參與者提供服務(wù);特定的參與者(particularactor):某人、某臺設(shè)備、某外部系統(tǒng)、等等,能夠觸發(fā)某些行為。用例描述(文本)是最要的,而不是圖形用例建模主要是編寫文本的活動,而非制圖用例(UseCase)特征(系統(tǒng))用例與業(yè)務(wù)用例區(qū)別業(yè)務(wù)用例不研究“軟件系統(tǒng)”需求,它更關(guān)心一個(gè)“業(yè)務(wù)組織”對外提供哪些服務(wù)。兩者的領(lǐng)域域不同業(yè)務(wù)用例模型僅關(guān)注于企業(yè)部門的業(yè)務(wù),而系統(tǒng)用例模型則關(guān)注于系統(tǒng)本身實(shí)現(xiàn)后的互動。UML圖素含有不同用例和功能區(qū)別(1)用例和功能區(qū)別(2)功能功能是脫離使用者愿望存在的功能是孤立的--只要按下開關(guān)就亮燈如果非用從功能的角度解釋用例,那么用例可以解釋為一系列完成一個(gè)特定目標(biāo)的“功能”的組合,針對不同的應(yīng)用場景,這些“功能”體現(xiàn)不同的組合方式用例和功能區(qū)別--功能分解主要缺陷(3)系統(tǒng)分析師必須高度仰賴以前開發(fā)過相似系統(tǒng)的經(jīng)驗(yàn),才能夠得知該將系統(tǒng)細(xì)分成哪幾個(gè)子系統(tǒng)、功能及子功能問題域無法直接對應(yīng)成功能,因此需要靠系統(tǒng)分析師以人工的方式來將問題領(lǐng)域?qū)?yīng)成功能與子功能。分解沒有定式,自由度較高,不同的分析師有不同的分析決定,所有結(jié)果難以理解,也難達(dá)成共識,同時(shí)日后也不易于重用與維護(hù)。整個(gè)系統(tǒng)有數(shù)個(gè)子系統(tǒng)所組成,每個(gè)子系統(tǒng)又由數(shù)個(gè)功能組成,每個(gè)功能再由數(shù)個(gè)子功能組成…,一層一層往下功能分解,再一層一層往上組成整個(gè)系統(tǒng)。由于功能變動性太大,也因此造成系統(tǒng)的結(jié)構(gòu)不穩(wěn)定HowtoWorkWithUseCasesinIterativeMethods?UsecasesarecentraltotheUPandmanyotheriterativemethods.TheUPencouragesuse-casedrivendevelopmentFunctionalrequirementsareprimarilyrecordedinusecasesUsecasesareanimportantpartofiterativeplanning.Use-caserealizationsdrivethedesignFunctionalorsystemtestingcorrespondstothescenariosofusecases.UI"wizards"orshortcutsmaybecreatedforthemostcommonscenariosofimportantusecasestoeasecommontasks.Usecasesofteninfluencetheorganizationofusermanuals.統(tǒng)一過程(UP)和用例(UseCase)Samplerequirementseffortacrosstheearlyiterations%WhenShouldVariousUPArtifactbeCreated?UseCase對開發(fā)的意義實(shí)現(xiàn)測試需求分析和設(shè)計(jì)UseCases把所有這些過程綁到一起OMT(ObjectModelingTechnique)方法的面向?qū)ο箝_發(fā)過程---Rumbaugh捕獲系統(tǒng)的需求便于和最終用戶、領(lǐng)域?qū)<医涣鳒y試系統(tǒng)需求與用例關(guān)系用例就是需求用例是真正的需求為功能性需求編寫用例,F(xiàn)URPS+強(qiáng)調(diào)F需求不是用例需求與用例關(guān)系什么是用例圖(usecasediagram)在UML中,一個(gè)用例模型由若干個(gè)用例圖(usecasediagram)描述。用例圖是顯示一組用例、參與者以及它們之間關(guān)系的圖。用例圖的組成一組用例(UseCases)一組參與者(Actors)一組關(guān)系(Relationships)Partialusecasecontextdiagram用例圖的應(yīng)用用例圖是從用戶的角度來描述對軟件產(chǎn)品的需求,分析產(chǎn)品的功能和行為,因此,對整個(gè)軟件開發(fā)過程而言,用例圖是至關(guān)重要的。用例圖定義和描述了系統(tǒng)的外部可見行為,是分析、設(shè)計(jì)直至組裝測試的重要依據(jù)。讓用戶參與前期的系統(tǒng)分析與設(shè)計(jì)。分析師必學(xué)元素識別參與者識別用例繪制用例圖編寫用例描述識別參與者參與者在系統(tǒng)之外,通過系統(tǒng)邊界與系統(tǒng)進(jìn)行直接有意義交互的任何事物系統(tǒng)外,而不是系統(tǒng)內(nèi)的責(zé)任的邊界,不是物理的邊界直接與系統(tǒng)交互執(zhí)行者與重要程度無關(guān)場景一:機(jī)票購買者是系統(tǒng)參與者場景二:人工座席是系統(tǒng)參與者,機(jī)票購買者是呼叫中心參與者場景三:呼叫中心(非人)是參與者,機(jī)票購買者是呼叫中心參與者場景四:機(jī)票購買者是參與者,人工座席是業(yè)務(wù)工人直接與系統(tǒng)交互有意義的交互任何事物,“非人”執(zhí)行者時(shí)間代理人時(shí)間代理人啟動時(shí)間酒店訂房系統(tǒng)確定參與者參與者一定是直接并主動向系統(tǒng)發(fā)出動作的參與者一定是能從系統(tǒng)獲得反饋的參與者與用戶用戶是系統(tǒng)的使用者用戶是系統(tǒng)的操作員用戶是參與者的實(shí)例或代表并非所有的參與者都是用戶如何區(qū)分參與者還是業(yè)務(wù)工人?最直接的方法是根據(jù)系統(tǒng)邊界,系統(tǒng)內(nèi)還是系統(tǒng)外如果邊界不確定,可以通過下面三個(gè)問題他是主動向系統(tǒng)發(fā)出動作嗎?他有完整的業(yè)務(wù)目標(biāo)嗎?系統(tǒng)是為他服務(wù)的嗎?如果以三個(gè)答案是否定的

,就一定是業(yè)務(wù)工人表1-11參與者的特征表參與者位于系統(tǒng)外部,他不屬于系統(tǒng)的某一部分,所以我們不需要去構(gòu)建參與者。只有會使用系統(tǒng)、會跟系統(tǒng)互動、會跟系統(tǒng)交換信息的才會是系統(tǒng)的參與者。參與者會啟動、參與用例,所以找到參與者,就可以引導(dǎo)我們找到用例。我們雖然不需要構(gòu)建參與者,但是卻需要考慮接口。系統(tǒng)需要提供接口讓參與者使用,或者系統(tǒng)需要用到參與者提供的接口---摘自:《系統(tǒng)分析師UML用例實(shí)踐》TheNextGenPOSSystem

anextgenerationfault-tolerantpoint-of-sale(POS)application,NextGenPOS,withtheflexibilitytosupportvaryingcustomerbusinessrules,multipleterminalanduserinterfacemechanisms,andintegrationwithmultiplethird-partysupportingsystems.表1-12尋找參與者的問題表誰會來使用這個(gè)系統(tǒng)?誰會來安裝這個(gè)系統(tǒng)?誰會來啟動這個(gè)系統(tǒng)?誰會來維護(hù)這個(gè)系統(tǒng)?誰會來關(guān)閉這個(gè)系統(tǒng)?那些系統(tǒng)會來使用這個(gè)系統(tǒng)?誰會從這個(gè)系統(tǒng)獲取信息?誰會給這個(gè)系統(tǒng)提供信息?在預(yù)選設(shè)定的時(shí)間到達(dá)時(shí),有什么事情會自動發(fā)生嗎?哪些系統(tǒng)會與這個(gè)系統(tǒng)聯(lián)網(wǎng)?哪些數(shù)據(jù)庫會與這個(gè)系統(tǒng)聯(lián)網(wǎng)?是否有硬件設(shè)備會與這個(gè)系統(tǒng)聯(lián)網(wǎng)?公司內(nèi)部會有哪些人員會來使用這個(gè)系統(tǒng)?公司外部有哪些人會來使用這個(gè)系統(tǒng)?當(dāng)特定的時(shí)間或事件發(fā)生時(shí),這個(gè)系統(tǒng)需要自動通知什么人,或者是自動通知其他系統(tǒng)嗎?---摘自:《系統(tǒng)分析師UML用例實(shí)踐》---Cashier/StoreManagerSystemAdministrator---SalesActivitySystem……---AccountingSystem/PaymentAuthorizationService表1-13參與者種類表種類細(xì)項(xiàng)參與者人公司外部的人公司內(nèi)部的人系統(tǒng)其他系統(tǒng)(內(nèi)部)其他系統(tǒng)(外部)數(shù)據(jù)庫事件硬件設(shè)備---摘自:《系統(tǒng)分析師UML用例實(shí)踐》CustomerCashier/StoreManager/SystemAdministratorSalesActivity/Accounting/HRSystemPaymentAuth/TaxCalculator

SystemUnknownTimmingUnknown思考題:識別參與者SP手機(jī)短信天氣預(yù)報(bào)系統(tǒng):用戶如果預(yù)定了SP的手機(jī)短信天氣預(yù)報(bào)業(yè)務(wù),系統(tǒng)每天會定時(shí)給他發(fā)天氣預(yù)報(bào)消息;如果當(dāng)天氣溫高于35度,還要提醒用戶注意防暑。在這個(gè)敘述里,SP天氣預(yù)報(bào)系統(tǒng)的Actor包括哪些?49如何識別用例(1)選擇系統(tǒng)邊界(2)確定主要參與者(3)確定每個(gè)主要參與者的目標(biāo)(4)定義滿足用戶目標(biāo)的用例,根據(jù)其目標(biāo)對用例命名。50(1)選擇系統(tǒng)邊界 例如:POS系統(tǒng),該系統(tǒng)之外的事物都在邊界之外。 如果對系統(tǒng)邊界的定義不清晰,可以通過對系統(tǒng)外部事物的定義加以明確。一旦定義了外部參與者,系統(tǒng)邊界將變得清晰51(2)(3)尋找主要參與者和目標(biāo)集體討論主要參與者特定參與者希望系統(tǒng)提供什么功能系統(tǒng)是否存儲和檢索信息,如果是,由哪個(gè)參與者觸發(fā)當(dāng)系統(tǒng)改變狀態(tài)時(shí),是否通知參與者是否存在影響系統(tǒng)的外部事件,哪個(gè)參與者通知系統(tǒng)這些事件52如何組織參與者和目標(biāo)有兩種方法1.當(dāng)你發(fā)現(xiàn)結(jié)果,將其繪制為用例圖,以目標(biāo)作為用例名稱2.首先寫出“參與者-目標(biāo)”列表,復(fù)審并精化,然后繪制用例圖?!皡⑴c者-目標(biāo)”列表,可以作為愿景制品的一部分。53為什么提問總是圍繞著參與者的目標(biāo)而不是用例參與者有其目標(biāo),并使用系統(tǒng)以達(dá)成這些目標(biāo)用例建模的觀點(diǎn)是尋找這些參與者及其目標(biāo),創(chuàng)建產(chǎn)生有價(jià)值結(jié)果的解決方案。建模時(shí)首先詢問“誰來使用系統(tǒng),他們的目標(biāo)是什么?”提問時(shí)問“你的目標(biāo)是什么”比問“你在做什么?”更適宜。前者的提問結(jié)果具有可量化的價(jià)值,后者只是概略性的面向任務(wù)的問題。54主要參與者是收銀員還是顧客圖6-2不同系統(tǒng)邊界下的主要參與者和目標(biāo)55有其它方法來尋找參與者和目標(biāo)嗎?-事件分析通過確定外部事件,可以有助于尋找參與者和目標(biāo)確定外部事件,源于何處,為什么?56(4)定義用例一般來說,為每個(gè)用戶目標(biāo)分別定義一個(gè)用例。用例名稱應(yīng)該和用戶目標(biāo)類似。用例名稱應(yīng)以“動詞+名詞”的形式命名,如:處理銷售,增加用戶等對于每個(gè)目標(biāo)一個(gè)用例來說,常見例外的是,將分散的CRUD目標(biāo)合成一個(gè)用例,并習(xí)慣稱為管理<X>.用例的要點(diǎn)表簡單記錄用例的結(jié)果、重要流程和議題,日后撰寫用例描述時(shí),這些可以作為參考資料用例要點(diǎn)說明<系統(tǒng)>結(jié)果重要步驟議題表1-16用例要點(diǎn)表---摘自:《系統(tǒng)分析師UML用例實(shí)踐》識別用例的注意事項(xiàng)注意事項(xiàng):可觀測→用例止于系統(tǒng)邊界結(jié)果值→用例是目標(biāo)導(dǎo)向的系統(tǒng)執(zhí)行→結(jié)果值由系統(tǒng)生成由參與者觀測→業(yè)務(wù)語言、用戶觀點(diǎn)執(zhí)行者視角-動詞+名詞識別用例填寫取款單不是取款人的目的,不是用例后臺監(jiān)控和輸入密碼對參與者是沒有意義的,不是用例ATM是沒有吐鈔的愿望的,因此不能驅(qū)動用例“喝”不能構(gòu)成一個(gè)完整的事件,因此不能用來命名用例可觀測→用例止于系統(tǒng)邊界結(jié)果值→用例是目標(biāo)導(dǎo)向的系統(tǒng)的存在是因?yàn)椋簠⑴c者有一些需要使用它來滿足的目標(biāo)不是某某做什么,而是某某【用系統(tǒng)】做什么結(jié)果值→有意義的目標(biāo)填寫取款單不是取款人的目的,不是用例系統(tǒng)執(zhí)行→結(jié)果值由系統(tǒng)生成系統(tǒng)需要處理的,由系統(tǒng)生成業(yè)務(wù)語言而非技術(shù)語言用戶觀點(diǎn)系統(tǒng)觀點(diǎn)用戶觀點(diǎn)而非系統(tǒng)觀點(diǎn)用戶觀點(diǎn)而非系統(tǒng)觀點(diǎn)用例

?呼叫某人

?接聽電話

?發(fā)送短消息

?記住電話號碼

?......

用戶觀點(diǎn)功能?傳輸/接收?電源/基站?輸入輸出(顯示,鍵盤)?電話簿管理?......系統(tǒng)觀點(diǎn)用例的問題表--便于幫助尋找用例參與者想要從這個(gè)系統(tǒng)獲得什么用的功能?這個(gè)系統(tǒng)存儲信息?哪些參與者將建立、讀取、更新或刪除這些信息?當(dāng)系統(tǒng)內(nèi)部狀態(tài)有變化時(shí),這個(gè)系統(tǒng)需要通知哪些參與者嗎?是否有什么外部事件是這個(gè)系統(tǒng)需要知道的?當(dāng)這些外部事件發(fā)生時(shí),那些參與者會通知這個(gè)系統(tǒng)?這個(gè)系統(tǒng)需要定期執(zhí)行什么操作嗎?當(dāng)發(fā)生了某些重要的外部事件時(shí),這個(gè)系統(tǒng)需要自動執(zhí)行什么操作嗎?這個(gè)用例的名稱夠明確嗎?是否能夠從這個(gè)用例的名稱,直接判斷他的結(jié)果?這個(gè)用例會有多樣的結(jié)果嗎?還是這些結(jié)果,其實(shí)是在不同的時(shí)間點(diǎn)產(chǎn)生的?表1-15用例問題表---摘自:《系統(tǒng)分析師UML用例實(shí)踐》……68發(fā)現(xiàn)有用用例的測試?yán)习鍦y試?yán)习逄釂枴蹦阏於甲隽诵┦裁??“,回答是什么?“登錄系統(tǒng)”?用例要產(chǎn)生可量化有價(jià)值的結(jié)果EBP(ElementaryBusinessProcess,基本業(yè)務(wù)過程)測試一個(gè)人于某個(gè)時(shí)刻在一個(gè)地點(diǎn)所執(zhí)行的任務(wù),用以響應(yīng)業(yè)務(wù)事件。該任務(wù)能增加可量化的業(yè)務(wù)價(jià)值,并且以持久姿態(tài)留下數(shù)據(jù)。如:批準(zhǔn)信用額度,確定訂購價(jià)格等與老板測試類以,強(qiáng)調(diào)”可量化有價(jià)值的結(jié)果規(guī)模測試用例通常包含多個(gè)步驟詳述形式的用例通常需要3-10頁文本。69示范:應(yīng)用上述測試就供應(yīng)商合同進(jìn)行協(xié)商比EBP更廣泛,用時(shí)更長。更適合作為業(yè)務(wù)用例,而非系統(tǒng)用例處理退貨能夠通過老板測試??瓷先ヅcEBP類似。規(guī)模合適。登錄如果你一整天都在登錄,老板不會滿意在游戲板上移動棋子單一步驟,不能通過規(guī)模測試70測試的合理違例子功能級別的用例,如:信用卡支付等子任務(wù),在多個(gè)基本用例中出現(xiàn)。雖然通不過EBP測試和規(guī)模測試,也需要考慮作為單獨(dú)用例認(rèn)證用戶這一用例可能無法通過老板測試,但其步驟及為復(fù)雜,需要引起重視進(jìn)行細(xì)致的分析,也可作為單獨(dú)用例要點(diǎn):用例的粒度(1)用例要有路徑,路徑要有步驟;而這一切都是可觀測的最常犯錯(cuò)誤:粒度過細(xì),陷入功能分解,過細(xì)的粒度一般都會導(dǎo)致技術(shù)語言的描述,而不再是業(yè)務(wù)語言把執(zhí)行者動作當(dāng)作用例把系統(tǒng)活動當(dāng)作用例要點(diǎn):用例粒度(2)把步驟當(dāng)用例把系統(tǒng)活動當(dāng)用例要點(diǎn):用例的粒度(3)“四輪馬車”C(Create)

R(Read)

U(Update)

D(Delete)所有業(yè)務(wù)最終都會成為CRUD?CRUD能為Actor提供價(jià)值?CRUD掩蓋業(yè)務(wù),銳變成關(guān)系數(shù)據(jù)庫的建模:“系統(tǒng)就是數(shù)據(jù)的增刪改查”關(guān)心數(shù)據(jù)的存儲和維護(hù),反而忽略了用戶的目的要點(diǎn):用例的粒度(4)如果確實(shí)是CRUD?如果CRUD不涉及復(fù)雜的交互,一個(gè)用例“管理××”即可不管是C、R、U、D,都是為了完成“管理”目標(biāo)甚至很多種的基本數(shù)據(jù)管理都可以用一個(gè)用例表示要點(diǎn):用例的粒度(5)階段粒度例子業(yè)務(wù)建模(描述功能性需求)用例名稱能夠說明一個(gè)完整業(yè)務(wù)流程取錢、報(bào)裝電話、借書等概念建模用例描述一項(xiàng)完整業(yè)務(wù)的一個(gè)步驟提供申請資料、受理業(yè)務(wù)等系統(tǒng)建模用例能夠描述操作者與計(jì)算機(jī)的一次完整交互為宜填寫申請單、審核任務(wù)單、驗(yàn)證密碼等粒度尚無標(biāo)準(zhǔn)規(guī)則建議在不同階段,使用不同粒度76應(yīng)用UML:用例圖用例圖用于描述用例名稱和參與者及其之間的關(guān)系。準(zhǔn)則:繪制簡單的用例圖,并與“參與者-目標(biāo)”列表關(guān)聯(lián)。77圖6-3部分用例語境圖78圖6-4表示法建議思考題:繪制用例圖SP手機(jī)短信天氣預(yù)報(bào)系統(tǒng):用戶如果預(yù)定了SP的手機(jī)短信天氣預(yù)報(bào)業(yè)務(wù),系統(tǒng)每天會定時(shí)給他發(fā)天氣預(yù)報(bào)消息;如果當(dāng)天氣溫高于35度,還要提醒用戶注意防暑。系統(tǒng)管理員、業(yè)務(wù)人員、用戶、時(shí)間代理、運(yùn)營商系統(tǒng)、媒體、數(shù)據(jù)分析系統(tǒng)用例描述除了用例圖之外,分析師還得使用文字描述用例的流程細(xì)節(jié),這樣的文字說明,又稱為“用例描述”(usecasedescription)。UML是一套標(biāo)準(zhǔn)的圖形語言,其中只提出了十四款圖,沒有將用例描述考慮在內(nèi),也當(dāng)然沒有任何標(biāo)準(zhǔn)的用例描述格式了。誰來寫用例描述最完美:業(yè)務(wù)人員接受訓(xùn)練,寫出優(yōu)美的用例文檔最現(xiàn)實(shí):業(yè)務(wù)人員提供素材,開發(fā)人員寫用例文檔最糟糕:業(yè)務(wù)人員不管,完全由開發(fā)人員杜撰82圖6-7編寫用例的過程和語境設(shè)置“編寫用例”在時(shí)間和地點(diǎn)方面的建議用例描述的四種形式命名(Giveitaname)僅僅給出用例和主要參與者的名稱摘要簡潔的一段式概要,通常用于主成功場景。例:P45處理銷售非正式用幾個(gè)段落覆蓋不同的場景。例如:P47處理退貨詳述詳細(xì)編寫所有步驟及各種變化,同時(shí)具有補(bǔ)充部分,如前置條件和成功保證。何時(shí)使用,在編寫了摘要形式的用例之后,在各個(gè)迭代階段之前精化需求時(shí)。例:P50處理銷售83用例敘述最簡版再怎么復(fù)雜的用例敘述,抽絲剝繭后,至少都會留下用例名稱,起點(diǎn)和終點(diǎn)表2-18用例敘述簡版用例:<名稱>事件流程:<起點(diǎn)>…<終點(diǎn)>---摘自:《系統(tǒng)分析師UML用例實(shí)踐》85以本質(zhì)(essential)風(fēng)格編寫用例;

摒除用戶界面并且關(guān)注參與者的意圖。本質(zhì)風(fēng)格……1.管理員標(biāo)識自己的身份2.系統(tǒng)對此身份進(jìn)行認(rèn)證3……具體風(fēng)格……1.管理員在對話框中輸入ID和口令(見圖3)2.系統(tǒng)對管理員進(jìn)行認(rèn)證3.系統(tǒng)顯示“編輯用戶”窗口(見圖4)4…….對根源目標(biāo)的發(fā)現(xiàn)過程能夠拓展視野,以促成新的、改進(jìn)的解決方案。用例描述組成(教材P50)用例的不同部分注解用例名稱UseCaseName動詞+名詞范圍Scope要設(shè)計(jì)的系統(tǒng)級別Level“用戶目標(biāo)”或者是“子功能”主要參與者PrimaryActor與系統(tǒng)交互完成服務(wù)涉眾及觀眾點(diǎn)StakeholdersandInterests關(guān)注該用例的人及其需求前置條件Preconditions值得告訴讀者,開始前必須為真的條件成功保證SuccessGuarantee值得告訴讀者,成功完成必須滿足的條件主成功場景MainSuccessScenario典型的、無條件的、理想方式的成果場景擴(kuò)展Extensions成功或失敗的替代場景特殊需求SpecialRequirements相關(guān)的非功能需求技術(shù)和數(shù)據(jù)變元表TechnologyandDataVariationsList不同的I/O方法和數(shù)據(jù)格式發(fā)生頻率FrequencyofOccurrence影響對實(shí)現(xiàn)的調(diào)查、測試和時(shí)間安排雜項(xiàng)Miscellaneous例如未決問題AlistairCockburn書寫用例描述總原則如果涉眾不能理解和驗(yàn)證,它就不是需求(如果刪除他,會不會有涉縱的利益受到傷害)總原則什么是涉眾涉眾是與要建設(shè)的業(yè)務(wù)系統(tǒng)相關(guān)的一切人和事。業(yè)主業(yè)務(wù)提出者業(yè)務(wù)管理者業(yè)務(wù)執(zhí)行者第三方承建方相關(guān)的法律法規(guī)用戶

涉眾利益涉縱利益需要整理?用例描述:前置條件指在用例場景開始前,必須永遠(yuǎn)為真的條件;

1)形式:系統(tǒng)在用例開始前能檢測到;

2)內(nèi)容:不滿足會傷害涉眾的利益前置條件開始用例前所必需的系統(tǒng)及其環(huán)境的狀用例描述:前置條件庫存大于下單數(shù)----錯(cuò)誤前置條件必須是系統(tǒng)在用例開始前能檢測到的用例描述:后置條件用例成功結(jié)束后,必須為真的事物,包括主成功場景及其替代路徑

1)系統(tǒng)能檢測到;

2)應(yīng)為“可觀測”的:只包含可檢測的條件,合并對系統(tǒng)最終影響相同的條件后置條件用例成功結(jié)束后系統(tǒng)應(yīng)該具備的狀態(tài)用例描述:后置條件前置條件和成功保證(后置條件)描述原則不要被其所困擾,除非對某些不明顯卻值得重視的事物進(jìn)行陳述、以幫助增強(qiáng)理解。用例描述:事件流用例描述的是一個(gè)系統(tǒng)做什么(what)的信息,并不說明怎么做(how),怎么做是設(shè)計(jì)模型的事用例描述:主成功場景也稱“基本事件流”或“理想路徑”,是對用例中常規(guī)、預(yù)期路徑的描述(有時(shí)被稱為Happyday場景),這是大多數(shù)用戶在大部分時(shí)間中所采取的路徑。把主要流程單獨(dú)分離,凸現(xiàn)用例的核心價(jià)值所有條件和分支延遲到擴(kuò)展部分進(jìn)行說明主成功場景核心的核心:客戶最想看到、最關(guān)心的路徑用例描述:擴(kuò)展事件流(替代流程)系統(tǒng)還需要進(jìn)行意外處理擴(kuò)展是重要的,通常占據(jù)了文本的大部分篇幅擴(kuò)展可針對一步,也可針對多步擴(kuò)展事件流替代流程的問題表在這個(gè)流程步驟中,是否還有其他替代的操作?在這個(gè)流程步驟中,是否會發(fā)生什么樣的錯(cuò)誤?在整個(gè)用例執(zhí)行過程中,是否隨時(shí)可能發(fā)生其他未記錄在敘述中的的操作?參與者輸入數(shù)據(jù)時(shí),是否會提供不完整的數(shù)據(jù),需要重新補(bǔ)上的數(shù)據(jù)?是否會出現(xiàn)錯(cuò)誤的數(shù)據(jù),需要特別處理的數(shù)據(jù)?參與者是否會在用例執(zhí)行期間,臨時(shí)中斷流程?參與者是否會想要挑選其他執(zhí)行方法?參與者在流程執(zhí)行過程中,會不會有需要協(xié)助的地方?系統(tǒng)發(fā)生宕機(jī)時(shí),是否需要特殊的處置?系統(tǒng)響應(yīng)時(shí)間過程時(shí),是否需要特殊的響應(yīng)方法?表2-19替代流程的問題表針對主要流程中的每一個(gè)步驟,都可以問問這些問題,對編寫替代流程很有幫助---摘自:《系統(tǒng)分析師UML用例實(shí)踐》替代流程分類表編寫替代流程的時(shí)候,可以直接按照這幾個(gè)類的替代流程來編寫替代流程替代1:不完整的數(shù)據(jù)替代2:錯(cuò)誤的數(shù)據(jù)替代3:取消或中端操作替代4:其他執(zhí)行方法替代5:需要協(xié)助替代6:系統(tǒng)宕機(jī)或無響應(yīng)表2-20替代流程分類表---摘自:《系統(tǒng)分析師UML用例實(shí)踐》用例事件流(交互)四步曲事件流描述要點(diǎn)只書寫“可理解、可驗(yàn)證、可觀測”的(說人話)每個(gè)步驟一個(gè)句子使用主動語句,理清責(zé)任句子必須以參與者或系統(tǒng)作為主語不要涉及界面細(xì)節(jié)分支和循環(huán)AlistairCockburn要點(diǎn)1:只寫“可觀測”的對特定參與者具有價(jià)值的可觀察的結(jié)果黑盒原則:規(guī)定系統(tǒng)做什么,而不是如何去做正確:系統(tǒng)記錄銷售錯(cuò)誤:系統(tǒng)通過ADO建立數(shù)據(jù)庫連接,傳送SQLInsert語句,將銷售記錄插入到商品表中…準(zhǔn)則:從系統(tǒng)外部的角度來編寫用例要點(diǎn)2:主動語句錯(cuò)誤:歐文從貝克漢姆處得到傳球,守門員…正確:貝克漢姆傳球給歐文,歐文射門,守門員撲救…錯(cuò)誤:系統(tǒng)從收銀員處獲得商品ID正確:收銀員輸入商品ID錯(cuò)誤:出售的商品被系統(tǒng)記錄正確:系統(tǒng)記錄出售的商品要點(diǎn)3:以參與者或系統(tǒng)作主語參與者……系統(tǒng)……1、顧客攜帶所購商品或服務(wù)到收銀臺通過POS機(jī)付款2、收銀員開啟一次新的銷售交易3、收銀員輸入商品條碼4、系統(tǒng)逐條記錄出售的商品,….…..要點(diǎn)4:不涉及界面細(xì)節(jié)錯(cuò)誤:收銀員從下拉框中選擇商品ID錯(cuò)誤:收銀員在對話框中商品ID錯(cuò)誤:收銀員在相應(yīng)文本框中輸入查詢條件錯(cuò)誤:收銀員點(diǎn)擊“確定”按鈕要點(diǎn)5:分支和循環(huán)分支:可以放到擴(kuò)展路徑參與者的選擇另一條成功線路系統(tǒng)進(jìn)行驗(yàn)證……循環(huán):直接描述…3、收銀員輸入商品條碼4、系統(tǒng)逐條記錄出售的商品,….

客戶重復(fù)步驟3、4,直到客戶指明他/她完成了選購…特殊需求SpecialRequirements非功能性需求、質(zhì)量屬性或約束性能可靠性可用性IO設(shè)備…技術(shù)和數(shù)據(jù)變元表TechnologyandDataVariationsList不同的I/O方法數(shù)據(jù)格式Example:MonopolyGame分析癱瘓警告警告4:別直到你知道用戶將要做什么為此才開始嘗試寫用例(Don'ttrytowriteusecaseuntilyouknowwhattheuserswillactuallybedoing)警告5:別花費(fèi)數(shù)周的時(shí)間,只是為了構(gòu)建出精致完善的用例模型Don'tspendweeksbuildingelaborate,elegantusecasemodelsthatyoucan'tdesignfrom)警告6:別浪費(fèi)時(shí)間去擔(dān)心、到底采用包含關(guān)系、擴(kuò)展關(guān)系等Don‘tspinyourwheelsworryingaboutwhethertouseincludes,extends,and/oruses警告7:別把時(shí)間浪費(fèi)在冗長且復(fù)雜的用例模板上Don'twastetimewit

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論