(面向对象设计)Part2INCEPTION

(面向对象设计)Part2INCEPTIONChapter4:InceptionisNottheRequirementsPhase

Lemieuxestl'ennemidubien(Thebestistheenemyofthegood).Voltaire4.1.WhatisInception?TheinitialstepofaprojectThevisionandbusinesscaseforthisprojectFeasibleBuyand/orbuildRoughunreliablerangeofcost:Isit$10K,100Korinthemillions?Proceedorstop?Thepurposeoftheinceptionphaseisnottodefinealltherequirements,orgenerateabelievableestimateorprojectplan.4.1.WhatisInception?Inceptioninonesentence:Envisiontheproductscope,vision,andbusinesscase.Themainproblemsolvedinonesentence:Dothestakeholdershavebasicagreementonthevisionoftheproject,andisitworthinvestinginseriousinvestigation?4.1.WhatisInception?AnanalogyIntheoilbusiness,Decideifthereisenoughevidenceorabusinesscasetoevenjustifyexploratorydrilling.Ifso,domeasurementsandexploratorydrilling.Providescopeandestimateinformation.

Furthersteps…

4.2.HowLongisInception?Especiallybrief.Iftheprojectwilldefinitelybedone,anditisclearlyfeasibleItincludesfirstrequirementsworkshopplanningforthefirstiteration4.3.WhatArtifactsMayStartinInception?ArtifactCommentVisionandBusinessCaseDescribesthehigh-levelgoalsandconstraints,thebusinesscase,andprovidesanexecutivesummary.Use-CaseModelDescribesthefunctionalrequirements.Duringinception,thenamesofmostusecaseswillbeidentified,andperhaps10%oftheusecaseswillbeanalyzedindetail.SupplementarySpecificationDescribesotherrequirements,mostlynon-functional.Duringinception,itisusefultohavesomeideaofthekeynon-functionalrequirementsthathavewillhaveamajorimpactonthearchitecture.GlossaryKeydomainterminology,anddatadictionary.RiskList&RiskManagementPlanDescribestherisks(business,technical,resource,schedule)andideasfortheirmitigationorresponse.Prototypes&proof-of-conceptsToclarifythevision,andvalidatetechnicalideas.IterationPlanDescribeswhattodointhefirstelaborationiteration.PhasePlan&SoftwareDevelopmentPlanLow-precisionguessforelaborationphasedurationandeffort.Tools,people,education,andotherresources.DevelopmentCaseAdescriptionofthecustomizedUPstepsandartifactsforthisproject.IntheUP,onealwayscustomizesitfortheproject.4.3.WhatArtifactsMayStartinInception?ALotofDocumentation!!!Choosetocreateonlythosethatreallyaddvaluefortheproject,Dropthemiftheirworthisnotproved.SincethisisevolutionarydevelopmentOnlyinitial,roughdocumentsistobecreatedduringthisphaseTheyarerefinedduringtheelaborationiterations4.3.WhatArtifactsMayStartinInception?AgileModelingperspectivethegreatestvalueofmodelingistoimprove

understanding,ratherthantodocumentreliablespecifications

InpreparingforbattleIhavealwaysfoundthatplansareuseless,butplanningindispensable.

GeneralEisenhower4.4.YouKnowYouDidn'tUnderstandInceptionWhen...Morethan"afew"weekslongformostprojects.Attempttodefinemostoftherequirements.Estimatesorplansareexpectedtobereliable.Definethearchitecture.Believethatthepropersequenceofworkdefinetherequirements;designthearchitecture;implement.NoBusinessCaseorVisionartifact.Alltheusecaseswerewrittenindetail.Noneoftheusecaseswerewrittenindetail;4.5.HowMuchUMLDuringInception?Thepurposeofinceptionistocollectjustenoughinformationtoestablishacommonvision,todecideifmovingforwardisfeasible,iftheprojectisworthseriousinvestigationintheelaborationphaseMostUMLdiagrammingwilloccurinthenextphaseelaboration.Chapter5:EvolutionaryRequirements

Oursisaworldwherepeopledon'tknowwhattheywantandarewillingtogothroughhelltogetit.DonMarquisObjectiveMotivatedoingevolutionaryrequirements.DefinetheFURPS+model.DefinetheUPrequirementsartifacts5.1.Definition:RequirementsRequirementscapabilitiesandconditionstowhichthesystem/projectmustconformManagerequirementsinUPAsystematicapproachtofinding,documenting,organizing,andtrackingthechangingrequirementsofasystem5.2.Evolutionaryvs.WaterfallRequirementsUnifiedProcessEmbracingchangeinrequirementsisincrediblyimportantandattheheartofwaterfallversusiterativeandevolutionarythinking.Waterfallpracticesviewasoftwareprojectassimilartopredictablemassmanufacturing,lowchangerates.Softwareisinthedomainofnewproductdevelopment,highchangerangeshighdegreesofnoveltyanddiscovery.5.2.Evolutionaryvs.WaterfallRequirementsSomeStatisticalresultsStudyfailurefactorson1027projects[1]Waterfallpracticesarethelargestcontributingfactorforfailure(82%)1.Thomas,M.2001.ITProjectsSinkorSwim.BritishComputerSocietyReview.5.2.Evolutionaryvs.WaterfallRequirementsJohnson,J.2002.ROIIt'sYourJob,XP2002,Sardinia,Italy.Actualuseofwaterfall-specifiedfeatures.

5.3.WhatareSkillfulMeanstoFindRequirements?SystematicapproachtohandlingthechangingrequirementsWritingusecaseswithcustomersRequirementsworkshopsthatincludebothdevelopersandcustomers

FocusgroupswithproxycustomersAdemooftheresultsofeachiterationtosolicitcustomer’sfeedback5.4.WhataretheTypesandCategoriesofRequirements?FURPS+modelFunctionalfeatures,capabilities,security.Usabilityhumanfactors,help,documentation.Reliabilityfrequencyoffailure,recoverability,predictability.Performanceresponsetimes,throughput,accuracy,availability,resourceusage.Supportabilityadaptability,maintainability,internationalization,configurability5.4.WhataretheTypesandCategoriesofRequirements?"+"inFURPS+Implementationresourcelimitations,languagesandtools,hardware,...Interfaceconstraintsimposedbyinterfacingwithexternalsystems.Operationssystemmanagementinitsoperationalsetting.Packagingforexample,aphysicalbox.Legallicensingandsoforth.5.5.HowareRequirementsOrganizedinUPArtifacts?UPoffersseveralrequirementsartifactsUse-CaseModelAsetoftypicalscenariosofusingasystem.(functionalrequirements)SupplementarySpecificationEverythingnotintheusecases.(non-functionalrequirements),Glossarydefinesnoteworthyterms.VisionSummarizeshigh-levelrequirements,summarizesthebusinesscasefortheproject.BusinessRulesdescriberequirementsorpoliciesthattranscendonesoftwareproject(ernmenttaxlaws).Questions&AnswersChapter6:UseCases

Theindispensablefirststeptogettingthethingsyouwantoutoflife:decidewhatyouwant. BenSteinObjectiveIdentifyandwriteusecases.Usethebrief,casual,andfullydressedformats,inanessentialstyle.Applyteststoidentifysuitableusecases.Relateusecaseanalysistoiterativedevelopment6.1ExampleProcessSale:Acustomerarrivesatacheckoutwithitemstopurchase.ThecashierusesthePOSsystemtorecordeachpurchaseditem.Thesystempresentsarunningtotalandline-itemdetails.Thecustomerenterspaymentinformation,whichthesystemvalidatesandrecords.Thesystemupdatesinventory.Thecustomerreceivesareceiptfromthesystemandthenleaveswiththeitems.6.2.WhatareActors,Scenarios,andUseCases?Actorsomethingwithbehavior,suchasaperson,computersystem,ororganization;forexample,acashierScenario(UseCaseInstance)aspecificsequenceofactionsandinteractionsbetweenactorsandthesystemoneparticularstoryofusingasystem,oronepaththroughtheusecaseforexample,thescenarioofsuccessfullypurchasingitemswithcash,thescenariooffailingtopurchaseitemsbecauseofacreditpaymentdenial.6.2.WhatareActors,Scenarios,andUseCases?UseCaseacollectionofrelatedsuccessandfailurescenariosthatdescribeanactorusingasystemtosupportagoal.Scenarios

Asetofuse-caseinstances,whereeachinstanceisasequenceofactionsasystemperformsthatyieldsanobservableresultofvaluetoaparticularactor

HandleReturnsMainSuccessScenario:Acustomerarrivesatacheckoutwithitemstoreturn.ThecashierusesthePOSsystemtorecordeachreturneditem…AlternateScenarios:Ifthecustomerpaidbycredit,andthereimbursementtransactiontotheircreditaccountisrejected,informthecustomerandpaythemwithcash.Iftheitemidentifierisnotfoundinthesystem,notifytheCashierandsuggestmanualentryoftheidentifiercode(perhapsitiscorrupted).Ifthesystemdetectsfailuretocommunicatewiththeexternalaccountingsystem,…6.3.UseCasesandtheUse-CaseModelUse-CaseModelmayoptionallyincludeaUMLusecasediagramtoshowthenamesofusecasesandactors,andtheirrelationships

Usecasesaretextdocuments,notdiagrams,anduse-casemodelingisprimarilyanactofwritingtext,notdrawingdiagrams.6.4.Motivation:WhyUseCases?Usecasesareagoodwaytohelpkeepitsimple,andmakeitfamiliartodomainexperts.emphasizetheusergoalsandperspectiveThebestaresimpleandfamiliar.

6.5.AreUseCasesFunctionalRequirements?Usecasesarerequirements,primarilyfunctionalorbehavioralrequirementsthatindicatewhatthesystemwilldo.6.6.WhatareThreeKindsofActors?PrimaryactorhasusergoalsfulfilledthroughusingservicesoftheSuD(SystemunderDiscussion)thecashier.SupportingactorprovidesaservicetotheSuD.theautomatedpaymentauthorizationserviceOffstageactorhasaninterestinthebehavioroftheusecase,butisnotprimaryorsupporting;agovernmenttaxagency.6.7.WhatareThreeCommonUseCaseFormats?Briefterseone-paragraphsummary,usuallyofthemainsuccessscenario.ProcessSaleCasualinformalparagraphformat.Multipleparagraphsthatcovervariousscenarios.HandleReturnsFullydressedallstepsandvariationsarewrittenindetail,andtherearesupportingsections6.8.Example:ProcessSale,FullyDressedStyleUseCaseSectionCommentUseCaseNameStartwithaverb.ScopeThesystemunderdesign.Level"user-goal"or"subfunction"PrimaryActorCallsonthesystemtodeliveritsservices.StakeholdersandInterestsWhocaresaboutthisusecase,andwhatdotheywant?PreconditionsWhatmustbetrueonstart,andworthtellingthereader?SuccessGuaranteeWhatmustbetrueonsuccessfulcompletion,andworthtellingthereader.MainSuccessScenarioAtypical,unconditionalhappypathscenarioofsuccess.ExtensionsAlternatescenariosofsuccessorfailure.SpecialRequirementsRelatednon-functionalrequirements.TechnologyandDataVariationsListVaryingI/Omethodsanddataformats.FrequencyofOccurrenceInfluencesinvestigation,testing,andtimingofimplementation.MiscellaneousSuchasopenissues.6.9.WhatdotheSectionsMean?PrefaceElementsScope:NextGenPOSApplicationboundsthesystem(orsystems)underdesignLevel:Usergoaluser-goalcommonkindthatdescribethescenariostofulfillthegoalsofaprimaryactortogetworkdonesubfunction-levelsubstepsrequiredtosupportausergoal(duplicatesubstepssharedbyseveralregularusecases).6.9.WhatdotheSectionsMean?PrimaryActor:CashierTheprincipalactorthatcallsuponsystemservicestofulfillagoal.StakeholdersandInterestsListreminduswhatthemoredetailedresponsibilitiesofthesystemshouldbe.StakeholdersandInterestsList(Example)CashierWantsaccurate,fastentry,andnopaymenterrors.Cashdrawershortagesaredeductedfromhis/hersalary.SalespersonWantssalescommissionsupdated.CustomerWantspurchaseandfastservicewithminimaleffort.Wantseasilyvisibledisplayofentereditemsandprices.Wantsproofofpurchasetosupportreturns.CompanyWantstoaccuratelyrecordtransactionsandsatisfycustomerinterests.WantstoensurethatPaymentAuthorizationServicepaymentreceivablesarerecorded.Wantssomefaulttolerancetoallowsalescaptureevenifservercomponentsareunavailable.Wantsautomaticandfastupdateofaccountingandinventory.StakeholdersandInterestsList(Example)ManagerWantstobeabletoquicklyperformoverrideoperations,EasilydebugCashierproblems.GovernmentTaxAgenciesWanttocollecttaxfromeverysale.PaymentAuthorizationServiceWantstoreceivedigitalauthorizationrequestsinthecorrectformatandprotocol.Wantstoaccuratelyaccountfortheirpayablestothestore.6.9.WhatdotheSectionsMean?PreconditionsandSuccessGuaranteesPrecondition:CashierisidentifiedandauthenticatedstatebeforeascenarioisbegunSuccessguaranteesstateonsuccessfulcompletionExamplesSaleissaved.Taxiscorrectlycalculated.AccountingandInventoryareupdated.Commissionsrecorded.Receiptisgenerated.Paymentauthorizationapprovalsarerecorded.6.9.WhatdotheSectionsMean?MainSuccessScenarioDescribesatypicalsuccesspaththatsatisfiestheinterestsofthestakeholders.RecordsthreetypesofstepsAninteractionbetweenactorsAvalidation.Astatechangebythesystem.MainSuccessScenario(Example)CustomerarrivesatPOScheckoutwithgoods(services).Cashierstartsanewsale.Cashierentersitemidentifier.Systemrecordssalelineitem,presentsitemdescription,price,andrunningtotal.Pricecalculated(pricerule).Cashierrepeatssteps3-4untilindicatesdone.Systempresentstotalwithtaxescalculated.CashiertellsCustomerthetotal,asksforpayment.CustomerpaysandSystemhandlespayment.Systemlogscompletedsaleandsendssale&paymentinformationtotheAccountingsystem/Inventorysystem.Systempresentsreceipt.Customerleaveswithreceiptandgoods.6.9.WhatdotheSectionsMean?Extensionsindicatealltheotherscenariosorbranches,bothsuccessandfailurenotatedwithrespecttoitssteps1…N.twoparts:theconditionandthehandling.conditioncanbedetectedbythesystemoranactor.Attheendofextensionhandling,bydefaultthescenariomergesbackwiththemainsuccessscenario6.9.WhatdotheSectionsMean?SpecialRequirementsnon-functionalrequirement,qualityattribute,orconstraintExampleTouchscreenUIonalargeflatpanelmonitor.Textmustbevisiblefrom1meter.Creditauthorizationresponsewithin30seconds90%ofthetime.Wantrobustrecoverywhenaccesstoremoteservices.Languageinternationalizationonthetextdisplayed.Pluggablebusinessrulestobeinsertableatsteps3and7.6.9.WhatdotheSectionsMean?TechnologyandDataVariationsListExample*a.Manageroverrideenteredbyswipinganoverridecardthroughacardreader,orenteringanauthorizationcodeviathekeyboard.3a.Itemidentifierenteredbybarcodelaserscannerorkeyboard.3b.ItemidentifiermaybeanyUPC,EAN,JAN,orSKUcodingscheme.7a.Creditaccountinformationenteredbycardreaderorkeyboard.7b.Creditpaymentsignaturecapturedonpaperreceipt.Butwithintwoyears,wepredictmanycustomerswillwantdigitalsignaturecapture.6.10.ATwo-ColumnVariationEmphasizestheinteractionbetweentheactorsandthesystem.Examples(inbook)6.11-6.14.Guidelines:WriteinanEssentialUI-FreeStyleKeeptheuserinterfaceout;focusonintentExample:LoginWriteTerseUseCasesWriteBlack-BoxUseCasesSpecifywhatthesystemmustdowithoutdecidinghowitwilldoit.TakeanActorandActor-GoalPerspectiveWriterequirementsfocusingontheusersoractors,askingabouttheirgoalsandtypicalsituations.Focusonunderstandingwhattheactorconsidersavaluableresult6.15.Guideline:HowtoFindUseCasesStep1:ChoosetheSystemBoundaryDefinetheactorfirst,thentheboundarybecomesclearer.Step2,3:FindPrimaryActorsandGoalsBrainstormtheprimaryactorsfirst,asthissetsuptheframeworkforfurtherinvestigation.

6.15.Guideline:HowtoFindUseCasesWhostartsandstopsthesystem?Whodoessystemadministration?Whodoesuserandsecuritymanagement?Is"time"anactorbecausethesystemdoessomethinginresponsetoatimeevent?Isthereamonitoringprocessthatrestartsthesystemifitfails?Whoevaluatessystemactivityorperformance?Howaresoftwareupdateshandled?Pushorpullupdate?Whoevaluateslogs?Aretheyremotelyretrieved?Inadditiontohumanprimaryactors,arethereanyexternalsoftwareorroboticsystemsthatcalluponservicesofthesystem?Whogetsnotifiedwhenthereareerrorsorfailures?QuestionstoHelpFindActorsandGoals6.15.Guideline:HowtoFindUseCasesHowtoOrganizetheActorsandGoals?Asyoudiscovertheresults,drawtheminausecasediagram,namingthegoalsasusecases.Writeanactor-goallistfirst,reviewandrefineit,andthendrawtheusecasediagram.6.15.Guideline:HowtoFindUseCasesActorGoalActorGoalCashierprocesssaleSystemAdministratorAddusersProcessrentalsModifyusersHandlereturnsDeleteusersCashinManagesecurityCashoutManagesystemtables…..…..6.15.Guideline:HowtoFindUseCasesWhyAskAboutActorGoalsRatherThanUseCases?Theviewpointofusecasemodelingistofindtheseactorsandtheirgoals,tocreatesolutionsthatproducearesultofvalue.Twoquestionsinrequirementsworkshop"Whatdoyoudo?""Whatareyourgoalswhoseresultshavemeasurablevalue?"6.15.Guideline:HowtoFindUseCasesIstheCashierorCustomerthePrimaryActor?Thesystemwasdesignedforthecashier,toquicklyprocessasale,lookupprices,etc

notforthecustomer.EventAnalysis--OtherWaystoFindActorsandGoalsidentifyexternalevents.Whatarethey,wherefrom,andwhy?

6.15.Guideline:HowtoFindUseCasesStep4:DefineUseCasesdefineoneusecaseforeachusergoalNametheusecasesimilartotheusergoal.Startthenameofusecaseswithaverb6.16.WhatTestsCanHelpFindUsefulUseCases?Whichoftheseisavalidusecase?NegotiateaSupplierContractHandleReturnsLogInMovePieceonGameBoard6.16.WhatTestsCanHelpFindUsefulUseCases?TheBossTestTheusecaseshouldbestronglyrelatedtoachievingresultsofmeasurablevalueTheElementaryBusinessProcess(EBP)TestEBPAtaskperformedbyonepersoninoneplaceatonetime,inresponsetoabusinessevent,whichaddsmeasurablebusinessvalueandleavesthedatainaconsistentstate.TheSizeTestAusecasetypicallycontainsmanysteps6.16.WhatTestsCanHelpFindUsefulUseCases?ApplyingtheTestsNegotiateaSupplierContractMuchbroaderandlongerthananEBP.HandleReturnsOKwiththeboss.SeemslikeanEBP.Sizeisgood.LogInBossnothappyifthisisallyoudoallday!MovePieceonGameBoardSinglestep.failsthesizetest.ReasonableViolationsoftheTestsExample:“payingbycredit”6.17.ApplyingUML:UseCaseDiagramsusecasediagramnotationillustratethenamesofusecasesandactors,andtherelationshipsbetweenthem.Acommonsignofanoviceusecasemodelerisapreoccupationwithusecasediagramsandusecaserelationships,ratherthanwritingtext.DownplayDiagramming,KeepitShortandSimple6.19.Motivation:RequirementsinContextAmotivationforusecasesisfocusingonwhothekeyactorsare,theirgoals,andcommontasksUsecasesorganizeasetofrequirementsinthecontextofthetypicalscenariosofusingasystem.improvescohesionandcomprehensionHigh-LevelSystemFeatureListsAreAcceptable6.20.Example:MonopolyGame6.21.HowtoWorkWithUseCasesinIterativeM