So, in case you haven’t visited before I’m writing a small game using a simple and very effective methodology. I’m also taking you, dear reader, along for the ride!
In our last post (Step 1: in which we figure out what our software is going to do) we reviewed the value of features in software development, and created a features list for our project. Features give us a good “birds eye view” of what our software is going to do.
The trouble with only knowing what your software is going to do is figuring out which one of a billion ways you’re actually going to make that happen. It’s easy to rush right in to code, which potentially (almost definitely) causes you to miss details that come back to bite you in the ass later. So, to help solve this we need a better understanding of the problem, which is hard to get if you’re only using big abstract ideas like features.
So, what we really need is to organize those features into smaller chunks that are easier to manage. One of the best ways to figure out what those chunks should be is by creating a list of possible use cases (stories detailing how users interact with the solution) which tell us how our software is going to be used. Once we know that, we can tie the use cases in with the features to break our software up into one or more sensible categories, or packages. I know that last sentence might not make much sense yet, but a lot of ninja training is pretty befuddling too, and ninjas-are-awesome, so but please bear with me. So, one of the most ninja-licious tools for figuring out how a system is going to be used is the use case diagram. Use case diagrams allow easy communication about the relationships between users and a solution. There are a lot of great tools for making them, but honestly you could draw it on a napkin and the results would be just as good (though slightly less professional looking).
The Use Case Diagram:
Use case diagrams are a common UML diagram showing the relationship between consumers of a solution (actors), and what those consumers actually do (use cases). For people who haven’t spent a lot of time with UML before, some explanation of the key elements you’ll see in the diagram is in order:
How not to make a use case diagram:
When people first start using use case diagrams it’s common to see them treated like an actual use case. While there is technically nothing wrong with writing use cases this way, that’s not what the diagram was created for. A bubble in a use case diagram is only supposed to convey the highest level of a use case, which enables us to see all our user interactions at a glance. If you really want a diagram to convey step-by-step information look up activity diagrams, but we won’t be using those here – in my experience a well written use case is a far more powerful design tool.
A better way to make a use case diagram:
Below you can see a use case diagram that is a little more well formed. The thing about this or any of the other steps we discuss is don’t get too hung up on making it perfect. All you need it to do is convey a clear idea about how the solution will be used, and if you don’t get it right the first time there will be plenty of opportunities to update it before you start coding. Software design is an iterative process of discovery – you will always find details you missed later on.
The Woebot use case diagram:
Now that we’re all on the same page with use case diagrams we can go ahead and make one for Woebot. I’m also going to include some of the UML stereotypes from the list of key elements above, though it’s perfectly acceptable to leave them out if you prefer.
Like most things in software development, everyone is going to bring their own style to the table, so don’t be surprised if you would have come up with a completely different set of use cases than what I have here. Now that we’ve got a general set of use cases we can add them to our Woebot Chapter 1: Design Document.
So, now that we know how our software is going to be used we can learn some Analysis Superpowers! Unfortunately that won’t be until
Step 3: In which we discover that our feature list sucks is written. In the meantime, I’d love to hear any feedback you have – Even if you think this article was a stupid waste of time (which it wasn’t, unless you don’t write software, in which case, maybe you need a hobby – I’ve heard writing software is a good one).