My Design Process – Use-Case Diagrams
I am currently doing a series of posts where I am documenting my personal software design process. This process has been developed to support the environment that my designs are currently deployed into – a fairly large retail company that needs to control the rate that applications are deployed to the stores in order to limit the number of distractions that threaten to pull the sales staff from their primary role of, well, selling.
I make no claim that this should be viewed as the “one-right way” to design applications. I imagine that I would have a radically different process if I were building publically facing websites for a conference. My goal is to document my process for solving the problems that I am facing.
Currently, my design process flows through the following stages
This stage involves the specification of the high-level components that make up the proposed software system and describes, very generally, how they will interact.
In the requirements gathering stage, all available documentation from the business owners are gathered and recorded. This often includes conversations with program management to ensure that each requirement is understood.
The requirements are then distilled down into individual use-cases that the software system will implement in order to meet the requirements. Also, the components that are likely involved in the use-case are identified.
Activity Diagrams and Wireframing
This stage involves the creation of activity diagrams (aka flow charts) to show how the user and system components will actually interact to implement each use-case. Also, since the interaction of the user and the system are starting the be specified, the structure of the user-interface (aka wireframes) are created at this time as well.
The final, and most time intensive stage, is the creation of sequence diagrams. These diagrams contain the detailed information about how the system operates to implement the process illustrated by the activity diagrams.
In this post, we’ll focus on one of the simplest, and most vital, parts of the process – the derivation of the use-cases. As the name implies a use-case is a description of one way that the system will be used. The “users” may be customers, employees, or even other software systems. Ideally, a use-case is described by a simple verb-noun pairing. This allows us to describe what the use-case is while avoiding the temptation to start talking about how that use-case will be implemented.
To illustrate this process, I would like to leave the world of software systems for a bit. The reason for this is that the concept, and the value that I derive from it is best illustrated in a distributed system. While I could start introducing an example that uses service-oriented architectures (SOA) and enterprise services buses (ESB), my goal is to make my process as easy to understand as possible and these abstract concepts would make that more difficult. Instead, let’s tackle something that most people have used, or at least heard of – a car.
A car is a distributed system because it is, in fact, not one machine, but many. We are all familiar with the fact that a car has an engine, a transmission, and brakes. Not surprisingly, there are many other systems that work together to move you safely down the highway at over 100 feet per second.
To start our discussion, we need to honor our first two steps – create a component diagram and gather requirements. In the interest of clarity, we will simplify our car quite a bit and use the following component diagram:
We’ll keep the requirements simple as well, let’s go with this list:
- Must be able to accelerate from 0 – 60 mph in 8 seconds
- Must be able to accelerate from 0 – 100 mph in 23 seconds
- Must be able to stop from 60 mph in 150 feet on dry asphalt pavement
- Turning circle to be a maximum of 38 feet
As you might imagine a real car is quite a bit more sophisticated and the requirements extend into the thousands, but I think this will be enough to get us going.
In my process, use-case diagrams are the first time in which requirements and the components of the system are joined together. This is a critical step in the process and sets us up for the rest of the design process. However, the diagrams that we generate are not all that sophisticated. As I’ve mentioned before, a use-case is ideally described by a simple verb-noun pair. I use them to link the actors of the system (i.e. the users) with the components of the system that will be involved in implementing the use-case. Additionally, I like to list the requirement(s) that are met by the use case in order to assure that we don’t lose sight of them as the design continues to evolve. Let’s build that up one step at a time.
All of the requirements involve the driver of the car interacting with the system. So, let’s start with them:
Like it? I thought you would. If not, then keep in mind – this is engineering, not art. The point is that we have identified an “actor” that will interact with the system. Now we need to identify a use-case for this actor. If we look at the first two requirements, it appears that the driver needs to be able to accelerate the car. Let’s add that use case to our diagram.
Okay, so far, so good. We understand one of the things that our car needs to do (accelerate). While this is technically a complete diagram, I add more information in order to help me document what components of the system will work to implement the use case. So, let’s think this through:
- A car should normally accelerate only in response to the driver’s request, so the driver controls will probably be involved
- The engine is what powers the car, since we need to add energy to the car to make it go faster, we’ll probably need the engine to provide it
- The wheels are what actually transmit the power to the road, so we’ll need them
- The transmission has a lot of jobs, but one of them is to transmit the energy from the engine to the wheels. Since the engine and wheels are involved, the transmission needs to be as well.
As a final part of this step, I like to highlight the interface that the actor will use to interact with the system by linking that to the use case. Putting it all together gives us this diagram:
Now we are getting some useful information. We have a very simple function that the system will provide (accelerate car) and the components of the system that will enable that function to happen.
As a final step, let’s document the requirements that this use case will be responsible for fulfilling. It looks like the first two requirements involve the acceleration of the car. Let’s add them to the diagram now:
With this last addition, we have documented a use-case of the system, the components that will be involved in providing that use-case, and the requirements that will have to be met in order to determine if the use-case was successfully implemented. As you can see, the diagram is relatively simple, but provides the vital function of bringing everything together.
A use-case diagrams primary responsibility is to document the actors of the system and the uses that they have for that system. We have extended that concept a bit to include the major subsystems that we think will come to play in providing the needed functionality. We have also included the requirements that determine whether the system is functioning properly or not. The next step in the process is the creation of wireframes, which will start to define our user-interface, and activity diagrams which will start to assign specific functions that each component will need to provide in order to implement the use-case. We’ll see how that happens next time.