Understanding use cases
Video: Understanding use casesOnce we've gotten some basic requirements together for the first iteration, our list of what this application must do. And this could be written in a requirements document or statement of work or just some bullet points on a white board. We can start to describe our app in more detail, and what we do in this step will make it much more obvious, the classes that we need to create, and to do this we switch our focus. We go from the feature focus requirements where we said the system must or the application must, now to a user focus.
Viewers: in countries Watching now:
Most modern programming languages, such as Java, C#, Ruby, and Python, are object-oriented languages, which help group individual bits of code into a complex and coherent application. However, object-orientation itself is not a language; it's simply a set of ideas and concepts.
Let Simon Allardice introduce you to the terms—words like abstraction, inheritance, polymorphism, subclass—and guide you through defining your requirements and identifying use cases for your program. The course also covers creating conceptual models of your program with design patterns, class and sequence diagrams, and unified modeling language (UML) tools, and then shows how to convert the diagrams into code.
- Why use object-oriented design (OOD)?
- Pinpointing use cases, actors, and scenarios
- Identifying class responsibilities and relationships
- Creating class diagrams
- Using abstract classes
- Working with inheritance
- Creating advanced UML diagrams
- Understanding object-oriented design principles
Understanding use cases
Once we've gotten some basic requirements together for the first iteration, our list of what this application must do. And this could be written in a requirements document or statement of work or just some bullet points on a white board. We can start to describe our app in more detail, and what we do in this step will make it much more obvious, the classes that we need to create, and to do this we switch our focus. We go from the feature focus requirements where we said the system must or the application must, now to a user focus.
How does the user accomplish a particular goal with our application? And the aim is to write these in everyday language as non-technical as possible. A typical user of this app should be able to read one of these descriptions and understand it. Now as ever, there is no one required way that you must write these, but there are two formats commonly used in this phase of the design process. One is called a Use Case, and the other is a User Story, and we're gonna talk about both. But first up, Use Cases.
use cases can be written at several levels of formality, but at the most essential they need three things: a title that describes the goal we're looking for, the person who wants that goal referred to as the Actor, and the steps needed to accomplish the goal--the actual Scenario here. Because we're not just describing an isolated feature but describing this interaction in full context, a complete step-by-step encounter which could have multiple possible results, including when things go wrong. Now the best title for a use case is a short phrase with an active verb.
Examples here might be Register new member, Transfer funds, Purchase items, Create new page, and so on. These could all be separate use cases, separate but distinct goals of the application. And then we have the actor. Now the reason that we say actor rather than generic user is because we often need to identify exactly who is having this interaction. It could be a user but also a customer, member, or administrator.
An application that has users in different roles would have different goals to describe for each of these roles, and it doesn't have to be a human being. It could be another computer system interacting with our application. So any external entity that acts on our system is an actor. Then we have the scenario, the details of accomplishing this one goal. Now this could be written as, say, a single paragraph, something like this. We talk about the customer reviews, items, and shopping cart, customer provides payment and shipping information, system validates payment information and responds with confirmation of order, and provides order number that a customer can use to check on the order status, and so on.
We're writing this so it's short and succinct and can be understood by a typical user of the application. It's also very common to write the scenario as individual steps, as a numbered list. So step 1, Customer chooses to enter the checkout process. Step 2, Customer is shown a confirmation page for their order, allowing them to change quantities, remove items or cancel, and so on. Now notice that I can go to a slightly different phrasing or different level of detail. That's perfectly all right. It's whatever makes sense for the situation.
Now either of these ways of describing this use case would be considered an informal or casual use case. We're describing the normal expected flow. Now depending on the situation, we may need to describe stock checking for physical items or download links for digital items. But we're describing a goal from the perspective of a user. This is not pseudocode. This is not something we take our Code Editor and start writing. We're not there yet, and we're not trying to be. Now depending on the situation, you can not only detail the main scenario, but you can also add extensions, steps for alternative flows like what happens when items are out of stock or for the order never finalized or for when things go wrong, like payment problems.
And if it's more useful, you can add some more specific details about the scenario. One common example would be a precondition. What must be true to begin this use case? Here perhaps the precondition would be a Customer has had at least one item to the shopping cart. That's the only way this use case makes sense. Now you can take it all the way to what's often referred to as a fully-dressed use case. Beyond the usual Title, Actor, and Scenario includes multiple placeholders for a trigger and description, preconditions, postconditions, who were the stakeholders in this? And these often exist as PDF templates or Word document templates that you can fill in. But be careful here.
Formality always sounds like a good idea, but requiring this level of detail can kill progress. In a very formal large project with team members spread across the globe, fully dressed use cases might be necessary. But for most projects, it's much better to have a set of readable casual use cases then a collection of super-formal multipage templates that never get completed. If it helps, here's some perspective on how long you should be spending on these. One or two days in any iteration would be a good goal.
If you're working with customers, you get together, you take over a conference room for a couple of days, and that's where you work through your requirements and your most important set of use cases as well, but as quickly as you can, so you can move onto the next phase. If you find yourself a month later still working on making perfect use cases, you're probably turning this into something it isn't meant to be. Now there are use case diagrams, but forget about the diagrams for a moment. use cases are first and foremost written texts. These are stories.
They are not diagrams. We will see the use case diagrams a little later, but as with all diagrams they're support for this, not a replacement. And before we get to diagrams, let's talk a little bit more about Scenarios and Actors.
There are currently no FAQs about Foundations of Programming: Object-Oriented Design.