The Art Of Writing Use Cases - Wirfs-Brock Associates
TheThe ArtArt ofof WritingWriting UseUseCasesCaseswww.wirfs-brock.comCopyright 2001, Wirfs-Brock Associates, Inc.1Rebecca Wirfs-Brockrebecca@wirfs-brock.comJohn Schwartzjohn@wirfs-brock.com
GoalsThe goal of this course is to enable you to– understand use case models: actors, use cases,glossaries and use case diagrams– use three forms of use case descriptions– write effective use case descriptions– critique use case descriptions– relate use cases to business policies, UIprototypes and other requirements– add detail and precision to use case descriptionsCopyright 2001, Wirfs-Brock Associates, Inc.2
AgendaUse Cases, Actors and GlossariesExercise 1: Find Use Cases and ActorsLet’s Tell a StoryExercise 2: Write Use Case NarrativesScenarios and Conversations: Tips andGuidelinesExercise 3: “Clinic” a ScenarioExercise 4: Write a ConversationAlternatives: Exceptions and VariationsExercise 5: Describing AlternativesCopyright 2001, Wirfs-Brock Associates, Inc.3
Scope of TutorialResponsibilityDriven AnalysisProblem DefinitionMarketing ListData ModelsState ModelsConceptualModelsConceptual ModelsProcess DescriptionsUsage CharacteristicsAssumptions & ConstraintsFunctional & Nonfunctional RequirementsDomain ConceptsSystem DescriptionUsage ModelActorsNarratives, Scenarios and ConversationsGlossaries: Concepts, Behaviors, etc.Activity DiagramsUser Navigation ModelUI PrototypeCandidate Domain ObjectsObject AnalysisCandidate ObjectsInformationEssential tyDriven DesignExploratory DesignRoles, Responsibilities andCollaborationsState ModelsControl ArchitectureCandidate ClassesClass Inheritance HierarchiesDesign Level ConversationsRefinementDecision & delegation modelsRefined class definitionsClass and Object DiagramsSequence diagramsPackagesCodeContractsInterface DefinitionsInvariants
UseUse Cases,Cases, ActorsActors andandGlossariesGlossariesCopyright 2001, Wirfs-Brock Associates, Inc.5
A ContextProcess TechniquesPrinciplesCopyright 2001, Wirfs-Brock Associates, Inc.6ProductInitialProblemValues
Tell a StoryCover the basics– Key requirements for your application: use cases,scalability, etc.– Glossary can assistUnfold your story– Choose the right form– Choose a level of detail appropriate to youraudience– Don’t tell everything at once. Reveal details asneeded– Consider different actors’ perspectivesCopyright 2001, Wirfs-Brock Associates, Inc.7
Use CaseFunctionality from a particular point-of-viewA collection of task-related activities.Online Banking Use Casesmaking a paymenttransferring funds between accountsreviewing account balances describing a discrete “chunk” of the systemUse cases describe a system from an external usageviewpointCopyright 2001, Wirfs-Brock Associates, Inc.8
Function and FormThe Writing TaskThe Use Case Form To UsePresent overviewDescribesequence andadd detailsCopyright 2001, Wirfs-Brock Associates, Inc.NarrativeScenario(step by step)9Conversation(dialog)
First Form: A NarrativeMake a PaymentThe user can make online payments to vendors andcompanies known to the bank. Users can applypayments to specific vendor accounts they have.There are two typical ways to make payments:the user can specify a one-time payment for aspecific amount, or establish regular paymentsto made on a specific interval such as monthly,bi-weekly, or semi-annually.Copyright 2001, Wirfs-Brock Associates, Inc.10
Narrative FormFree-form text in paragraph formatDescribes the intent of the user in performing the usecaseDescribes high-level actions of the user during the usecaseRefers to key concepts from the problem domain thatare involved in the use case.Copyright 2001, Wirfs-Brock Associates, Inc.11
Second Form: A ScenarioRegister Customer With Automatic Activation1User enters registration information:Required information: user name, email address, desired login ID andpassword, and confirmation passwordOne of: account number and challenge data, or ATM # and PINOptional: language choice and company2System checks that password matches confirmation password.3System validates required fields and verifies uniqueness of login ID4System verifies customer activation information.5System creates and activates customer online account.6System displays registration notification.Copyright 2001, Wirfs-Brock Associates, Inc.12
Scenario FormOne particular path through a use case written from theactor’s point of viewDescribes a sequence of events or list of steps toaccomplishEach step is a simple declarative statement with nobranchingMay describe:– Actors and their intentions– System responsibilities and actionsCopyright 2001, Wirfs-Brock Associates, Inc.13
Third Form: A ConversationMake A PaymentGeneralFlowActor: UserSystem: ApplicationPresent list of payment templates touser organized by payee categorySelect a payment templatePresent details of selected PaymentTemplate and recent paymenthistory to payeeOptionalActionEnter payee notes, amount andaccountSubmit payment informationApply payment to payeeAdd new payment to recentpayment listRedisplay the payment listOptionally, request Setup PaymentsSelect next functionGoto Edit Payment TemplateInformationGoto selected use caseInvoking AnotherUse Case14Copyright 2001, Wirfs-Brock Associates, Inc.MultipleActions
Conversation FormOne path through a use case that emphasizesinteractions between an actor and the systemCan show optional and repeated actionsEach action can be described by one or moresubstepsMay describe:– Actor actions– System responsibilities and actionsCopyright 2001, Wirfs-Brock Associates, Inc.15
Comparing the Three FormsFormNarrativeStrengths Good for highlevel summariesand intentions Can beimplementationindependent Good forstep-by-stepsequencesWeaknesses Easy to write at too highor too low a level Not suitable for complexdescriptions Can be ambiguous aboutwho does whatScenario Hard to show parallelism,arbitrary ordering oroptionality Can be monotonousConversation Good for seeing Easy to write to pseudoactor-systemcodeinteractions Difficult to show Can show parallelrepetitionand optionalactionsAll Forms Informal InformalCopyright 2001, Wirfs-Brock Associates, Inc.16
The Benefits of Use CasesUse cases describe a system from an externalusage perspectiveThey can be organized according to theirrelevance, frequency of use, and perceivedvalue to the system’s usersSystem features can be correlated with how theyare used within specific use casesImpacts of adding and/or removing features onsystem usability can be analyzedCopyright 2001, Wirfs-Brock Associates, Inc.17
Use Cases Aid UnderstandingCapture information in a natural wayUsers:“You mean we’ll have to ?”Discover “holes” in the understanding of asystemSponsors:“You left out one thing here .”Organize work supported by the systemDevelopers:“Hmm, these aren’t just a bulletedlist of functions!”Copyright 2001, Wirfs-Brock Associates, Inc.18
Use Cases Vary by AbstractionLevelSteve Registers for English 101, orStudent Registers for Course, orUser Uses System, orStudent Registers for Variable Credit Course, orStudent Registers for Music CourseCopyright 2001, Wirfs-Brock Associates, Inc.19
Use Cases Vary in ScopeWhich system boundary do we mean?component: describing the web appletapplication: online bankingorganization: the bankWe typically start by describing application levelscopeCopyright 2001, Wirfs-Brock Associates, Inc.20
Use Cases Vary in DetailDo we describe general actions?Enter deposit amountor specific details?Press number keys followed by enter keyWrite at the level that seems appropriate to yourreadersThis typically means describing actor actions andsystem responses that match the goal for the usecaseCopyright 2001, Wirfs-Brock Associates, Inc.21
What Use Cases Cannot DoUse Cases are best used to describe systemfunctionality from a task-oriented perspectiveThey do not describe:– user interfaces– performance goals– application architecture– non-functional requirementsCopyright 2001, Wirfs-Brock Associates, Inc.22
Finding Use CasesDescribe end user goals supported by thesystem “Transfer money between accounts.”“Get money.”“Make payments.”“Set up vendors for automatic payments ”Copyright 2001, Wirfs-Brock Associates, Inc.23
Finding Use CasesDescribe the functions that the user will wantfrom the systemDescribe the operations that create, read,update, and delete informationDescribe how actors are notified of changes tothe internal state of the systemDescribe how actors communicate informationabout events that the system must knowaboutCopyright 2001, Wirfs-Brock Associates, Inc.24
Naming Use CasesName a use case with a verb-noun phrase that states theactor’s goalUse concrete, “strong” verbs instead of generalized, weakerones. Weak verbs may indicate uncertainty– Strong Verbs: create, merge, calculate, migrate,receive, archive, register, activate– Weaker Verbs: make, report, use, copy, organize,record, find, process, maintain, listBe explicit. Use specific terms. They are stronger– Strong Nouns: property, payment, transcript, account– Weaker Nouns: data, paper, report, system, formCopyright 2001, Wirfs-Brock Associates, Inc.25
Different Perspectivesuseroperatormake paymenttransfer fundsedit configurationmaintain user infoOracledatabaseadministratoradd bank agentlegacy systemCopyright 2001, Wirfs-Brock Associates, Inc.26
ActorAny one or thing that interacts with the systemcausing it to respond to business eventsSomething that– stimulates the system to react (primary actor), or– responds to the system’s requests (secondaryactor)Something we don’t have control overCopyright 2001, Wirfs-Brock Associates, Inc.27
Primary and Secondary ActorsPrimary Actor— Any one or thing that interactswith the system causing it to respond to businesseventsSomething we don’t have control overSecondary Actor— Something or someone thatresponds to system requestsSomething the system uses to get its job doneCopyright 2001, Wirfs-Brock Associates, Inc.28
Naming ActorsGroup individuals according to their common use of thesystem. Identify the roles they take on when they useor are used by the systemEach role is a potential actorName each role and define its distinguishingcharacteristics. Add these definitions to your glossaryDon’t equate job title with role name. Roles cut acrossjob titlesUse the common name for an existing system; don’tinvent a new name to match its roleDon’t waste time debating actor namesCopyright 2001, Wirfs-Brock Associates, Inc.29
Places to Look for ActorsWho uses the system?Who gets information from this system?Who provides information to the system?What other systems use this system?Who installs, starts up, or maintains the system?Copyright 2001, Wirfs-Brock Associates, Inc.30
Finding ActorsFocus initially on human and other primary actorsGroup individuals according to their common tasks andsystem useName and define their common roleIdentify systems that initiate interactions with the systemIdentify other systems used to accomplish the system’stasksUse common names for these other “system” actorsCopyright 2001, Wirfs-Brock Associates, Inc.31
Actor and Use Case ChecklistWhat system requirements are not represented byuse cases?Document those that are internal to the system (can’t beseen by actors) elsewhereDo all actors and use cases have descriptive names?Do those that need explanation have short descriptions?Are system boundaries and scope clear?Are areas of uncertainty documented asassumptions and issues?Copyright 2001, Wirfs-Brock Associates, Inc.32
FindFind ActorsActors andand UseUse CasesCasesCopyright 2001, Wirfs-Brock Associates, Inc.33
GlossariesCopyright 2001, Wirfs-Brock Associates, Inc.34
GlossaryA glossary is a central place for:– Definitions for key concepts– Clarification of ambiguous terms andconcepts– Explanations of jargon– Definitions of business events– Descriptions of software actionsThe glossary is built incrementallyCopyright 2001, Wirfs-Brock Associates, Inc.35
Build ConsensusAgree on the problem to be solved!Define terms in a glossary– Identify similar behaviors that havedifferent names– Identify different behaviors that have thesame name– Choose ONE definition!Use team development and reviewCopyright 2001, Wirfs-Brock Associates, Inc.36
Defining ConceptsIdentify a concept and its distinguishingcharacteristicsMore than a synonym for a wordIdentifies a way of mentally dividing reality forpurpose of talking or thinkingCopyright 2001, Wirfs-Brock Associates, Inc.37
Writing Glossary EntriesWhy this concept is importantTypical sizes or valuesClarify likely misunderstandingsShow an exampleExplain graphical symbolsRelate entriesCopyright 2001, Wirfs-Brock Associates, Inc.38
A Good Form for DefinitionsName of Concept related to a Broader Concept CharacteristicsContrast: A compiler is a program that translatessource code into machine languageWith a definition that leaves out context: Acompiler translates source code into machinelanguageWhat performs this translation? A computer? Aperson?Copyright 2001, Wirfs-Brock Associates, Inc.39
Improving Glossary DefinitionsContrast the original:Account In the online banking system there are accounts within thebank which customer-users can access in order to transfer funds,view account balances and transaction historical data, or makepayments. A customer has one or more accounts which, onceapproved by the bank can be accessed. The application supportsthe ability for customers to inform the system of new accounts,and for the customer to edit information maintained about theaccounts (such as name and address information).With a definition that says what an account is and how it is used:Account An account is a record of money deposited at the bankfor checking, savings or other uses. A customer may haveseveral bank accounts. Once a customer’s account is activated foronline access, account information can be reviewed andtransactions can be performed via the internet.Copyright 2001, Wirfs-Brock Associates, Inc.40
Another RevisionAutomatic activation. Automatic activation is an optionalfunction of the online banking software that enablesimmediate access to bank accounts. To automaticallyactivate an account, a customer provides information thatassociates him with an account, called challenge data, such asmother’s maiden name. Online access is granted once thechallenge data is validated against bank records. Alternatively,the customer can supply a valid ATM bankcard number andPIN. All accounts associated with that ATM card would beactivated.Characteristics:– Optional feature– Details of how the automatic activation functionworksCopyright 2001, Wirfs-Brock Associates, Inc.41
Relating DefinitionsCustomer-user. A customer-user is a person who has online access tobanking accounts. One or more customer-users are associatedwith a customer. Each customer-user can have different accessprivileges to and visibility of a customer’s accounts. For example, ina small business, the accounting customer-user might make vendorpayments from an account, while a business manager may simplyview an account’s transaction history.Examples add to but don’t replace definitionsCustomer. A customer is a person or organization with one or morebank accounts. Customers do not use the online banking system,their customer-users do.Characteristics:– How a customer-user relates to a customer– What distinguishes one from anotherCopyright 2001, Wirfs-Brock Associates, Inc.42
Use Pictures to Relate Conceptswire center— the geographical area served by a central officecentral office— a building where local call switching takes placemain distribution frame— a large connector at a central office,which connects switching equipment to feeder cablesfeeder cable— a large cable that connects to the main distributionframe at a central office and feeds into distribution cablesdistribution cable— a cable that connects between a feeder cableand one or more terminalsCopyright 2001, Wirfs-Brock Associates, Inc.43
A Picture RelatingHierarchical Conceptsterminalswire centercross connectcentral officemaindistributionframeCopyright 2001, Wirfs-Brock Associates, Inc.connector blocksfeeder cables44
Define AcronymsandExample:Their ConceptsOSS— Operations Support System: As definedby the FCC, a computer system and/ordatabase used at a telephone company for preordering, ordering, provisioning, maintenanceand repair, or billingCopyright 2001, Wirfs-Brock Associates, Inc.45
Avoid Using“Is When” or “Is Where”Definitions using these words are often missingthe broader conceptContrast: An overplot is an overlap betweentwo or more graphic entities drawn at thesame place on a pageWith:An overplot is when two things overlapCopyright 2001, Wirfs-Brock Associates, Inc.46
Explain What Is UnclearUpgrading to Next Day Air does not mean you will get yourorder the next day.Once shipped, Next Day Air packages are guaranteed to arriveat the end of the next business day. Note that upgrading methodof shipment to Next Day or 2nd Day Air does not change howlong it takes to assemble and ship an order – it only reduces thetravel time after an order leaves the warehouse. For example,an item marked as “Usually ships within 2 to 3 days” andupgraded to Next Day Air will usually leave our warehouse onthe 2nd or 3rd business day and reach you on the 3rd or 4thbusiness day.Copyright 2001, Wirfs-Brock Associates, Inc.47
Let’sLet’s TellTell aa StoryStoryCopyright 2001, Wirfs-Brock Associates, Inc.48
Setting the StageLevel— summary, core, supporting, or internal use case?Actor(s)— role names of people or external systemsinitiating this use caseContext— the current state of the system and actorPreconditions— what must be true before a use case canbeginScreens— references to windows or web pagesdisplayed in this use caseCopyright 2001, Wirfs-Brock Associates, Inc.49
Completing The PictureVariations— different ways to accomplish use case stepsExceptions— errors that occur during the execution of a stepPolicies— specific rules that must be enforced by the use caseIssues— questions about the use caseDesign notes— hints to implementersPost-conditions— what must be true about the system after a usecase completesOther requirements— what constraints must this use case conformtoPriority— how important is this use case?Frequency— how often is this performed?Copyright 2001, Wirfs-Brock Associates, Inc.50
A Use Case TemplateUse case namePreambleUse case body (narrative, scenario or conversation)Supplementary details and constraintsCopyright 2001, Wirfs-Brock Associates, Inc.51
Narrative FormFree-form text in paragraph formatDescribes the intent of the user in performing the usecaseDescribes high-level actions of the user during the usecaseRefers to key concepts from the problem domain thatare involved in the use case.Copyright 2001, Wirfs-Brock Associates, Inc.52
Make Clear What You Don’t KnowWrite questions about unsolved issuesPut them with the appropriate use case description toshow you’re not doneExample:Should the credit check be performed after theOrder is submitted or before?What happens if credit is denied?If you are unclear about a detail, don’t write fiction; itcould become fixedCopyright 2001, Wirfs-Brock Associates, Inc.53
Avoid Vague Words“Depends on,” in writing, is ambiguousExample:XYZ depends on the following software might mean: The following software must be complete beforeprogrammers at ABC can begin developing XYZ The following software produces data processedby XYZ The following software must be installed on anycomputer on which XYZ is to runCopyright 2001, Wirfs-Brock Associates, Inc.54
Writing a Use Case NarrativeName the use case with an active verb phrase describingthe user’s goalWrite a paragraph explaining the user’s intent, whatshould happen to achieve the goal, and some keyfacts about the processIdentify terms that should be definedAnnotate and reference other requirements that the usecase satisfiesTell this “story” from a single point of view (the user’s)Copyright 2001, Wirfs-Brock Associates, Inc.55
WriteWrite UseUse CaseCase NarrativesNarrativesCopyright 2001, Wirfs-Brock Associates, Inc.56
ScenariosScenarios andand Conversations:Conversations:TipsTips andand GuidelinesGuidelinesCopyright 2001, Wirfs-Brock Associates, Inc.57
Write General and Specific CasesChoose this option when your audience needs bothgeneral and specific usage descriptionsHigh-level use case names state a general goal. Write onenarrative use case for each general goal:Narrative: Make a paymentDescribe what online payment means and typical ways of making themWrite scenarios or conversations that describe morespecific goals:Scenario 1: Make a recurring paymentAll the steps in paying my monthly phone bill Scenario 2: Make a non-recurring paymentAll the steps in paying a fixed amount Scenario 3: Make a regular paymentAll the steps in paying a monthly loan Copyright 2001, Wirfs-Brock Associates, Inc.58
Write Two “Versions” of theSame Use CaseChoose this option when some want a quick idea, whileothers want to see the detailsFirst, write a narrativeThen, choose an appropriate form. Rewrite the use casebody at this lower-level of detailLeave the narrative as an overviewConsider adding an “overview” section to your template ifyou have always have diverse readers for your use casedescriptionsCopyright 2001, Wirfs-Brock Associates, Inc.59
Writing Scenarios andConversationsStart by writing the success story, the “happypath”Capture the actor’s intentions and responsibilities,from beginning to end goalDefine what information passes between thesystem and actor but don’t describe its formator detailsCopyright 2001, Wirfs-Brock Associates, Inc.60
Writing Scenarios andConversationsAll steps should be visible to or easily surmisedby the actorResist the temptation to get too detailedConvey how the system will workBe clear on where to startDescribe how the goal is achievedEnd thereCopyright 2001, Wirfs-Brock Associates, Inc.61
ScenarioOne particular path through a use case writtenfrom the actor’s point of viewDescribes a sequence of events or list of steps toaccomplishEach step is a simple declarative statement withno branchingMay describe:– Actors and their intentions– System responsibilities and actionsCopyright 2001, Wirfs-Brock Associates, Inc.62
Record IssuesClearly distinguish what you know from whatyou need to find outAssign responsibility to a stakeholder forresolving an issueWrite and attach these to a specific descriptionCopyright 2001, Wirfs-Brock Associates, Inc.63
Online Banking ScenarioScenario: Register Customer with Auto-Activation1User enters registration information:Required information: user name, email address, desired login ID and password,and confirmation passwordOne of: account number and challenge data, or ATM # and PINOptional: language choice and company2System checks that password matches confirmation password.3System validates required fields and verifies uniqueness of login ID4System verifies customer activation information.5System creates and activates customer online account.6System displays registration notification.Copyright 2001, Wirfs-Brock Associates, Inc.64
Include Actor ActionsBe explicit about what the actor does. Don’t disguise themas “system collects” or “system captures”actionsActor actions disguised as system activities:Scenario: Withdraw Fixed Cash Amount (Fast Cash)1.2.3.4.Present transaction screenCapture fast cash withdrawal requestPost transaction to bank and receive confirmationDispense money, card and transaction receiptFixed:Scenario: Withdraw Fixed Cash Amount (Fast Cash)1.2.3.4.ATM presents transaction screenCustomer selects “Fast Cash” optionATM posts fast cash amount withdrawal transaction to bank and receivesconfirmationATM dispenses money, card and transaction receiptCopyright 2001, Wirfs-Brock Associates, Inc.65
Include System ActionsBe explicit about what the system doesNo system behavior described:Scenario: Withdraw Fixed Cash Amount (Fast Cash)1. Customer selects “Fast Cash” option2. Customer takes cash, card and receiptFixed:Scenario: Withdraw Fixed Cash Amount (Fast Cash)1. ATM presents transaction screen2. Customer selects “Fast Cash” option3. ATM posts fast cash amount withdrawal transaction to bankand receives confirmation4. ATM dispenses money, card and transaction receiptCopyright 2001, Wirfs-Brock Associates, Inc.66
Describing ActionsShow actor intent, not precise movementsIntention: User enters name and addressMovements:System asks for nameUser enters nameSystem prompts for addressUser enters addressUse simple grammarSubject verb direct object prepositional phraseThe system deducts the amount from the account balanceWrite actions that move the process forward“Validate that ,” don’t “Check whether”Copyright 2001, Wirfs-Brock Associates, Inc.67
Condense Information Entryand/or Validation ActionsList of Seemingly Unrelated Items:Enter nameOptionally, enter addressOptionally, enter telephone numberFixed:Enter personal information (required: name; optional:address and phone number)Copyright 2001, Wirfs-Brock Associates, Inc.68
State System Actions At aReasonably High LevelIncludes Too Many Low Level Details and Substeps:System opens connection to the bankSystem requests authorization of bankcard number and PIN #Bank confirms bankcard and PIN are validSystem requests active accounts for bankcardBank returns account listSystem creates active online account entries for each accountFixed:System validates bankcard and PIN #sSystem activates accounts associated with bankcardMake sure what is going on, and why is it is being done is obvious tothe typical reader. Know your audienceCopyright 2001, Wirfs-Brock Associates, Inc.69
Showing Optional and RepeatedActionsMake clearOptionally, select an available course sectionwhether a step is In any order, do one or more of the following:optionalIndent severaloptional stepseatdrinkmake merryNext .Merge cells toRepeatindicate thebeginning andend of a block ofrepeated oroptional actionsactions go hereUntil proposed schedule is builtCopyright 2001, Wirfs-Brock Associates, Inc.70
Writing a ScenarioUse a listRecord action stepsRecord actor and system actions, identifyingeachScenario 1 NameScenario 2 Name1. System does this first1. System does this first2. Actor first does thisActor:3. Actor next does this2. First does this3. And then does thisCopyright 2001, Wirfs-Brock Associates, Inc.71
“Clinic”“Clinic” aa ScenarioScenarioCopyright 2001, Wirfs-Brock Associates, Inc.72
ConversationresponseactionCopyright 2001, Wirfs-Brock Associates, Inc.73
Conversation FormOne path through a use case that emphasizesinteractions between an actor and the systemCan show optional and repeated actionsEach action can be described by one or moresubstepsMay describe:– Actor actions– System responsibilities and actionsCopyright 2001, Wirfs-Brock Associates, Inc.74
Make a PaymentConversationGeneralFlowActor: UserSystem: ApplicationPresent list of payment templates touser organized by payee categorySelect a payment templatePresent details of selected PaymentTemplate and recent paymenthistory to payeeOptionalActionEnter payee notes, amount andaccountSubmit payment informationApply payment to payeeAdd new payment to recentpayment listRedisplay the payment listOptionally, request Setup PaymentsSelect next functionGoto Edit Payment TemplateInformationGoto selected use caseInvoking Another Use CaseCopyright 2001, Wirfs-Brock Associates, Inc.75MultipleActions
Maintain a Consistent Level ofDetailDo not mix intent, action and detail in the sameuse caseWrite at a level that seems appropriate to yourreadersThis typically means describing actions, notminute detailsDescription within a use case should be at thesame level of abstraction ( one)Copyright 2001, Wirfs-Brock Associates, Inc.76
Maintain a Consistent Level of DetailMixed level of detail:123Check for required fieldsCapture user ID and passwordAsk security component for validationIssue SQL statements to security database for logonauthorization Open connection to bank serverRead account summaries Fixed:123Check for required fieldsLogin user to domainDisplay account summaries and bulletinCopyright 2001, Wirfs-Brock Associates, Inc.77
Choosing BetweenConversations and ScenariosUse a scenario when:– a simple list of actions is sufficient– actor-system interactions aren’t interestingUse a conversation when:– there are many interactions and you want todescribe them– you want to show more detailed system responses– you want to separate the roles of actor and systemCopyright 2001, Wirfs-Brock Associates, Inc.78
Don’t Embed AlternativesConversation: Registration with Automatic-Activation10. If bank supports automatic activationwith ATM and PIN then.If ATM and PIN #s are valid then.Fixed:Conversation: Registration with Automatic-Activation10. Validate ATM and PIN #Exception – Step 10: ATM and PIN #s are invalid— Reporterror to userCopyright 2001, Wirfs-Brock Associates, Inc.79
Leave Out Information Formatsand Validation RulesUser Name: First name, last name (24 characters max, space delimited)email address with embedded @ sign signifying break between useridentification and domain name which includes domain and subdomain names delimited by periods and ending in one of: gov, com,edu.Fixed:Required: user name, email address, desired login ID and passwordOne of: account number and challenge data, or ATM # and PINOptional: Company NameDocument information model details in a separate place!Copyright 2001, Wirfs-Brock Associates, Inc.80
Don’t Mention Objects inSystem ActionsObjects mentioned:Create customer and account objectsFixed:Record customer account informationReme
- understand use case models: actors, use cases, glossaries and use case diagrams - use three forms of use case descriptions - write effective use case descriptions - critique use case descriptions - relate use cases to business policies, UI prototypes and other requirements - add detail and precision to use case descriptions
Silat is a combative art of self-defense and survival rooted from Matay archipelago. It was traced at thé early of Langkasuka Kingdom (2nd century CE) till thé reign of Melaka (Malaysia) Sultanate era (13th century). Silat has now evolved to become part of social culture and tradition with thé appearance of a fine physical and spiritual .
May 02, 2018 · D. Program Evaluation ͟The organization has provided a description of the framework for how each program will be evaluated. The framework should include all the elements below: ͟The evaluation methods are cost-effective for the organization ͟Quantitative and qualitative data is being collected (at Basics tier, data collection must have begun)
On an exceptional basis, Member States may request UNESCO to provide thé candidates with access to thé platform so they can complète thé form by themselves. Thèse requests must be addressed to esd rize unesco. or by 15 A ril 2021 UNESCO will provide thé nomineewith accessto thé platform via their émail address.
̶The leading indicator of employee engagement is based on the quality of the relationship between employee and supervisor Empower your managers! ̶Help them understand the impact on the organization ̶Share important changes, plan options, tasks, and deadlines ̶Provide key messages and talking points ̶Prepare them to answer employee questions
Dr. Sunita Bharatwal** Dr. Pawan Garga*** Abstract Customer satisfaction is derived from thè functionalities and values, a product or Service can provide. The current study aims to segregate thè dimensions of ordine Service quality and gather insights on its impact on web shopping. The trends of purchases have
Chính Văn.- Còn đức Thế tôn thì tuệ giác cực kỳ trong sạch 8: hiện hành bất nhị 9, đạt đến vô tướng 10, đứng vào chỗ đứng của các đức Thế tôn 11, thể hiện tính bình đẳng của các Ngài, đến chỗ không còn chướng ngại 12, giáo pháp không thể khuynh đảo, tâm thức không bị cản trở, cái được
ART 110 . Art Appreciation (2) ART 151 . Introduction to Social Practice Art (3) ART 281 . History of Western Art I (3) ART 282 . History of Western Art II (3) ART 384 . Art Since 1900 (3) ART 387. History of Photography (3) ART 389 . Women in Art (3) ENGL 270 . Introduction to Creative Writing (3)* HON 310 . Art in Focus (3)** each semester .
Oct 22, 2014 · ART ART 111 Art Appreciation ART 1301 Fine Arts ART 113 Art Methods and Materials Elective Fine Arts . ART 116 Survey of American Art Elective Fine Arts ART 117 Non Western Art History Elective Fine Arts ART 118 Art by Women Elective Fine Arts ART 121 Two Dimensional Design ART 1321 Fine Arts ART
