Skip to main content

The problem with use cases

The greatest benefit I get from use cases is that they focus on the user. Use cases help me to think about what the user wants to do instead of only focusing on implementation details.

The biggest problem I have with use cases is that they are not structured. They are basically free text. For instance, if we have a use case Withdraw money from ATM, we may define that it has a precondition that Open account is performed, but we don't get any help from the method to see that.

What happens if someone later changes the Open account use case or defines a Close account use case? How do we find which other uses cases that need to be modified? We can look through the old use case diagrams and find dependencies, but I can almost guarrantee that these dependencies have not been maintained after they were initially created.

The solution to this is to connect the use cases to an object model. I don't mean a use-case realization with view and controller objects like ATM_Screen and ATM_Session, I mean the model objects from the problem domain, such as Customer, Account and Transaction. These are the terms you use when you discuss the functionality with actual users.

If you model the Withdraw money from ATM use case as objects, it could be something like this:
  1. You have an Account object with balance $1000.
  2. You insert a card in an ATM and enters the pin code 1234.
  3. You withdraw $100 from the ATM.
  4. Afterwards, the Account balance is changed to $900 and a new Transaction is created.


To find dependencies between this use case and other use cases, we ask where the Account object and balance came from. This is something to discuss with the client or end users. They may answer that you can open an account and deposit cash.

The Open account use case can be modeled as follows:
  1. The customer gives name and address and shows id to a teller.
  2. Create an Account object.

The Deposit cash use case can be modeled as follows:
  1. You have an Account with balance $0.
  2. The customer gives the account number 12345678 and $1000 in cash to a teller.
  3. The Account balance is updated to $1000.

There you have the dependencies between Open account, Deposit cash and Withdraw money from ATM: They all use Account objects.

Analyze objects to find more functionality

We can continue with our analysis by asking questions such as:
  • Can the balance be changed in any other way than Deposit cash and Withdraw money from ATM?
  • Where did the Account number come from? Can it be changed?
  • How is the pin code set?
  • Can Accounts be deleted?
  • In which ways can you read Account numbers, balances and pin codes?
  • How can Transactions be created, updated, read and deleted?

The questions above deal with creation, deletion, update and reading of domain objects. They will help to discover more functionality, which can be analyzed further, and so on, until you have a very complete functional specification.

There are a few more questions that can be helpful to discover more functionality. They are based on 4 kinds of classes: People, places, things and events.
  • Ask which people will perform the various functionality. This will help us to model users, roles and privileges.
  • Finally, ask which information to store about user actions (events). Transaction is such a class that stores information about changes of Account balance.

This method is a fast way to come up with lots of requirements which would otherwise take days or weeks of brainstorming. It is similar to use cases in that focuses on what the users can do. But it is different in that it models this as objects. Therefore, I am calling this method object cases.

What exactly is an object case?

An object case is a use case scenario connected to domain objects. It consists of 4 parts:
  1. Initial objects
  2. Input
  3. Output
  4. Result objects

The input, output and objects are specified with concrete values. In my experience, this improves communication with clients and end users, because it reduces misunderstandings and help to find missing details.

Object cases are also a great help for developers; they have all the information they need in the object case and don't need to ask for clarifications so much.

Testers can also benefit from object cases. Instead of writing test specificiations based on use cases or some other abstract requirements, the object cases are ready to test.

Objects can also be used for project planning: Develop the functionality around a domain class together. Start with the function that creates objects of that class.

Comments

Popular posts from this blog

Database dump with Java

I need to update a database that is created by PHP. The problem is that I am not a PHP coder, but a Java coder, and I need to use some other Java libraries to get the job done. So how can find out exactly which tables to update and how? It would take me weeks to search the PHP code, and I still wouldn't be sure if I got it right.

The first step is to install a clean application on my computer. There is no user data in the database, so if I perform commands like creating a user etc in the web application, I can look at what changed in the database. I'm sure that could be done in MySQL, but I'm not an expert on that either. When the only tool you have is a hammer, everything looks like a nail. So, I'll use Java for that to.

So, I wrote a small Java application that produces exactly the output that I need. It reads metadata from the database to find all tables and columns, lists that metadata and the content of all the rows.

Here it is:import java.io.FileNotFoundException;
im…

The Future of Programming

The problem with abstractions Programmers are experts in abstract thinking. To program is to generalize: A method is a general specification of different execution paths. A class is a general specification of objects. A superclass is a generalization of several classes.

Although our minds are capable of abstract thinking, concrete thinking is more natural, and concrete examples are the foundation for abstractions. For instance, how do you teach children what a car is? You don't give a definition like: 'A car is a wheeled motor vehicle used for transporting passengers.' Instead, you point at a car and say: 'Look, a car!' After seeing a few cars, the child understands what a car is.


Notice what I just did! I started with a general principle and then gave an example. Which part of the paragraph above is easier to understand, the first sentence (general) or the rest (example)?

Einstein said that examples is not another way to teach, it is the only way to teach. It is…

World War 2, Rationalism and Agile Development

One of the central values of the Agile Manifesto is Responding to change over following a plan. This doesn't mean that it's not agile to make a plan. You should have a plan, but you should realize the limitations of the plan.

Are there any parallels to this in history?

The Soviet Union had 5-year plans. Stalin was quite succesful in industrializing the rural country in a short span of time. But his methods did not work well in the battlefield. In the 2nd world war, the Soviet suffered severe losses in the beginning.

You can plan how to build and manage a factory, because the complexity is limited. But a war is far more complex. You cannot predict what the enemy is going to do. This doesn't mean that you should go to war without a plan. Far from it, you should plan as much as possible, but be prepared to improvize when something unexpected happens. As Dwight D. Eisenhower, a successful American general in World War 2, said: "Plans are nothing; planning is everything."…