ibm.comdeveloperWorks : Components : OO design process: Use cases, an introductionIBM Home Products Consulting Industries News About IBM SearchIBM : developerWorks : Components library OO design process: Use cases, an introductionDesigning the dynamic (runtime) behavior of a programAllen HolubChief Technical Officer, NetRelianceJanuary 2001Contents: Introducing usecases Presenting a usecase Summing up Resources About the authorIn previous articles, we've refined the problem statement and mocked-up oureducational software. In this article we'll look at use-case analysis.This article continues my series on the OO-design process. The first four partsare:Getting started● Beginning to design software● Refining the problem definition● Verifying the analysis● This month I move on to analyzing the dynamic (runtime) behavior of the program. I'll do that byintroducing the notion of a use case and talking about how one of these beasts is organized. Nextmonth, I'll put this organization into the framework of the Bank of Allen.Introducing use casesThe "problem statement" looks pretty good at this point. I've probably forgotten something critical, butthere's no point in sitting around hoping that these missing pieces will spring from my head, fullyarmed, like Athena from the head of Zeus. By moving on and looking at the same problem in adifferent way, these missing pieces will become evident. The next step, then, is to look at the problemagain, but this time from the perspective of dynamic (i.e. runtime) behavior. In a sense, the problemstatement is a static definition of the problem -- it describes the problem that the user has to solve, butthat's it. Eventually, I'll formalize this view of the system into something called a static model.The dynamic definition of the problem focuses, not on what has to be done, but on how you do it. Thatis, rather than looking at the problem itself, we'll look at the things the users have to do to solve theproblem. The main tool we'll use to structure our thinking on that dynamic behavior is use-caseanalysis. Dynamic behavior can also be formalized into something called the dynamic model, butbefore we can do that, we have to figure out what the dynamic behavior is. We'll do this using use-caseanalysis.First of all, a definition:A use case is a single task, performed by the end user of a system, that has some usefuloutcome. developerWorks : Components : OO design process: Use cases, an introduction http://www-106.ibm.com/developerworks/library/co-design5.html (1 of 10) [1/10/2001 3:30:24 PM]The definition of "end user" and "outcome" can vary -- an end user might be an automated subsystem,for example, and the nature of the outcome can vary radically from use case to use case. Sometimes theoutcome is a physical product like a report, sometimes is an organizational goal, like hiring anemployee. But there's always an outcome that has a perceived (by the user) value.You can think of a use case in terms of user intent. If a user walks up to the system with the intent ofdoing something, what is that "something?" Logging on is not a full-blown use case, for example, sincenobody walks up to the system with the intent of doing nothing but logging on. You're logging on inorder to accomplish some other larger end, to perform some useful task, and the use case is thedefinition of that larger task.Presenting a use caseAs is often the case in software, an organized semiformal presentation of the use cases helps you getorganized. The formal presentation typically involves several pieces, listed in Table 1. (I'll explainwhat each section contains momentarily.) It's probably best to look at Table 1 as a checklist rather thana fill-in-the-blanks form. Not all sections are relevant in every use-case definition, and any of thesections can be combined (or omitted) in a real working document.Moreover, though the categories in Table 1 must all be addressed, they don't need to be addressed inthe order specified in the table. Often, it's best to start with the scenarios, develop them into a formalworkflow definition, and then fill in the other details. The ordering in Table 1 is really for theconvenience of the implementer, not the creator, of the use case.We designers have several major goals in creating use cases:Develop an increased understanding of the problem.1. Communicate with the end users to make sure we're really solving their problems.2. Organize the dynamic behavior of the design (and the resulting program) to reflect the actualbusiness model in the user's mind. In other words, assure that the program actually doessomething useful for a real user.3. Provide a road map and organizational framework for the actual development process. (More onthis in a few months when we start talking about implementation.)4. Table 1. The components of a formal use case presentationNameDescriptionDesired outcomeUser goalsParticipants/RolesDependenciesPreconditionsScenariosWorkflowPostconditionsBusiness rulesRequirementsImplementation notesdeveloperWorks : Components : OO design process: Use cases, an introduction http://www-106.ibm.com/developerworks/library/co-design5.html (2 of 10) [1/10/2001 3:30:24 PM]Use-case definition is a collaborative process. Many of these components are specified by thebusiness-side (typically marketing) organization, and others are filled in or expanded by thetechnical-side organization. The user-interface design is also an important component of use-caseanalysis. A UI mock up (not a prototype) provides a lot of useful feedback about whether we'vecaptured the use cases correctly. I'll come back to use-case-based UI design next month.For now, let's expand on Table 1 and spell out the sections of the document in detail.NameAll use cases should be named. Constantine recommends using a gerund followed by a direct object(for example: "withdrawing funds" or "examining the passbook"). This convention encourages theuse-case name to succinctly identify the operation being performed and the object (or subsystem) that'saffected by the operation. I think that this recommendation is fine as far as it goes, but there's noparticular benefit to rigidly following a formula if you end up omitting important information as aconsequence. For example, "customer withdrawing funds from checking account" might be a differentuse case than "bank manager withdrawing funds from customer's checking account." A simple"withdrawing funds" is not a sufficiently descriptive