Skip to main content
skip to main content

developerWorks  >  SOA and Web services  >

The OO design process: Use-case planning

Designing the dynamic (runtime) behavior of a program

Document options

Document options requiring JavaScript are not displayed

Rate this page

Help us improve this content

Level: Introductory

Allen Holub (, Chief Technical Officer, NetReliance

01 Mar 2001

In my last column, I introduced the notion of a formal use-case presentation. Use cases will be covered in the next several installments of this column. They are a complex topic, and there is a lot of material to cover, so we'll take our time and look at the issues thoroughly. This month we focus on how to decide which use cases to pursue, and other things we need to keep in mind as we plan our use cases.

Creating use cases

Let's start with a reprise of the definition of use case from last month:

A use case is a single task, performed by the end user of a system, that has some useful outcome.

Looking at the Bank of Allen problem statement from prior months, a few use cases spring out at me:

  • Kid depositing funds into an account
  • Kid withdrawing funds from an account
  • Kid or parent viewing a passbook
  • Parent opening an account
  • Parent changing an account
  • Parent closing an account
  • Bank loaning funds to a kid (defer to version 2)

At this stage, this list is just guesswork. I'm sure that I'll discover additional use cases as the process unfolds. Moreover, some of these use cases might turn out to be large enough that they will have to be decomposed into smaller chunks. (In general, by the time we get to an implementation-level design, no use case should take longer than a month to implement. In fact, one-person-month-per-use-case is a good rule-of-thumb metric for rough estimation. Some methodologies -- such as Kent Beck's XP -- want use cases that are small enough to be implementable in a couple of weeks.) Note that the low-level atomic operations -- such as computing interest -- aren't listed, since they aren't stand-alone use cases. These will almost certainly be subcases, though.

Now that I have something down on paper, I can start designing. Looking at the previous list, I've several thoughts. First, I'm not sure whether "depositing" and "withdrawing" are separate use cases. The alternative would be something like "perform a transaction," where "transaction" was either a deposit or withdrawal operation. Two use cases that turn out to have the same workflow are certainly equivalent, but I don't yet know whether that will be the case. For now, I'll keep both use cases since they appear to be different from the user's perspective, and they have different apparent outcomes. (Deposit increases the balance and withdrawal decreases it. The "perform a transaction" use case modifies the balance.)

Turning my attention to "viewing a passbook," I'm not sure that it's a use case at all. There's no particular outcome, and the passbook will most likely be displayed during the course of the other use cases. On consideration, I change this one to "playing what-if games," which does have an outcome: learning financial planning.

Next, I consider opening, closing, and changing an account. There are certainly distinct outcomes from the user perspective, but again, I can imagine that the workflow would be identical for the "opening" and "changing" cases. Certainly the UI would be identical -- it's just that various fields would be blank when you opened the account. The trivial differences could be handled with simple conditional branches ("if account is new, then ...") in the workflow.

I decide that "closing an account" is a real, though trivial, use case since the UI will be different than the UI for the opening/changing case. I don't want to do what a normal bank does and automatically close an account if the balance is exactly $0.00, because I can easily imagine kids taking their accounts down to a zero balance, and I don't want to redo the setup in that situation.

Finally, I decide to toss the "loaning funds" use case. It's a good version 2 feature, but I don't need it immediately.

Note that as I make these decisions, I'm imagining implementation details (the UI). I am, after all, designing a computer program, so I need to look forward toward implementation. Nonetheless, I'm simultaneously trying to keep my thinking in the problem domain for as long as possible. I'm using an imagined implementation to help understand domain-level issues, but I'm not designing that implementation, and I'm not wedded to it. The UI, then, is a design aid that helps me clarify my thinking about domain-level problems. This is a very different approach than the VB-style approach recommended by Alan Cooper, in which the UI design drives the program-design process. Here, the program will fall from the conceptual model, and the UI is just a convenient tool in developing that conceptual model.

Things like "backing up," "saving," etc, are not use cases because they don't occur in the problem domain. This also tells us something about how the program should work, however. It shouldn't be necessary to explicitly "save" before exiting any program, especially this one. If you make a deposit, you make a deposit. It's just unnatural to require an additional operation like saving for that deposit to be realized. I can guarantee that your average 10-year-old won't think about saving before exiting. If you think about it, requiring a "save" operation is the same thing as making "throw away all my work" the default behavior of a program -- not a particularly good default, if you ask me. Same for "backing up." Either the program should back up automatically as a side effect of changing the state of an account, or the program must maintain an audit trail that lets you undo the changes. It's rare that any operation that doesn't appear at the domain level should appear in the UI. Possible exceptions might include "help," but if the UI is sufficiently intuitive, help shouldn't be necessary. You could also argue that the program should notice when you need help by watching your behavior, and offer it to you at that time. Most configuration options are never changed by users, so there's no point in cluttering up the UI with that kind of junk. (Exceptions, of course, being configuration issues that appear in the problem domain, such as currency representation, though even that could be done automatically by detecting the current locale.)

The tentative use-case list now looks like this.

  • Kid depositing funds into an account
  • Kid withdrawing funds from an account
  • Playing what-if games
  • Parent opening or changing an account
  • Parent closing an account

Over the next two columns, I'll continue the exercise by formally specifying the "depositing funds" use case in depth. I'll present the specification itself along with extensive comments about what I'm doing.

Back to top


Back to top

About the author

Allen Holub is the Chief Technical Officer at NetReliance, a San-Francisco-based company that's building a secure global infrastructure for conducting trusted business transactions over the net. He has worked in the computer industry since 1979, and is widely published in magazines (Dr. Dobb's Journal, Programmers Journal, Byte, MSJ, among others). He writes the "Java Toolbox" column for the online magazine JavaWorld, and also writes the "OO Design Process" column for the IBM developerWorks Components zone now hosted on the IBM developerWorks Web services zone. He also moderates the ITworld Programming Theory & Practice discussion group. Allen has eight books to his credit, the latest of which covers the traps and pitfalls of Java threading ( Taming Java Threads ). He's been designing and building object-oriented software for longer than he cares to remember (in C++ and Java). He teaches OO design and Java for the University of California, Berkeley, Extension (since 1982). Contact Allen via his Web site

Back to top

Rate this page

Please take a moment to complete this form to help us better serve you.

YesNoDon't know



Back to top

    About IBMPrivacyContact