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.
They're that good, seriously
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).
While you can do your design work on napkins, your boss may not actually be all that thrilled...
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.
How not to make a use case diagram
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.
A better way to make a use case diagram
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.
The use case diagram for Woebot: Chapter 1
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).
Ugh, even as a cartoon, I *still* can’t stand looking at UML diagrams. It’s hopeless for me, isn’t it?
Definitely not, they’re an acquired taste :-)
Only in so much as you have to acquire a lack of taste…
UML is dreadful.
I feel you there, UML – like a lot of standards in software development – was probably made by a group of j-holes out to ruin everyone’s day.
There are a couple of good things about it though. One, is that since it’s a standard it gives everyone some shared common knowledge for discussing ideas – so everyone familiar with the standard can grasp what you’re trying to convey with relative ease (even if the experience is like drinking day old coffee through your eyeballs). The other (and most important), is that the process of modeling an idea before writing code gets developers thinking about the problem early. It takes a lot less time to change a line or two in a diagram than it does to rewrite code.
*Edit (#11, I’m really bad at this :D)
This was a vey nice article. As we know pictures are worth thousands words. Great job Eagan :)
I infer from above that a single use case can satisfy multiple featuers of the system. Please, correct me if i am wrong. Use case Diagrams are really helpful in finding out any missing features which we can alwasy add later.
I love reading it, please keep up the great job :). I am looking forward for 3rd step.
Thanks very much for reading it, Rizwan! I think you’re right in that thinking about the problem from a user perspective will definitely help you think of features you hadn’t thought of before. The other handy part to making use case diagrams is that it lets you use the features to categorize everything you need to do into logical packages or “systems” (more on this in the next article) – which really defines how you build the project from there (and if you have a small team this will help you distribute the workload to allow them to more/less work independently). There’s a lot of other useful things you can do with them (that we’ll cover later on), but the absolute best part is that putting yourself in the users shoes (even if only for a little while) will help you form a deeper understanding of what you hope to create.
Thanks again for the awesome feedback! I really appreciate it!
Keep em comin Eagan, definitely reading them now that I know this is here. (google+) I’ve wanted to learn UML for a while but I’ve only used it to map out classes and interfaces, etc in the past. I was operating under the false premise that I “didn’t have time for UML” because of the deadlines. Coming around to how much time it saves.
I’ll say this though, that one of the biggest deterrents I had was finding a UML tool that was easy to use and didn’t create more problems than it solved with respect to who can view it when. I found Lucid Chart (lucidchart.com) and it’s pretty f’n awesome. I’ve been using that for a while now for flowcharts and it’s become one of those ever so precious tools I use every day. Curious if you’ve heard of it (it allows real time collaboration). I’m hoping the tool can save you some time and help you write more articles? ;)
Anyhoo, that said I hope you keep pumping this thread, I found this (and your writing style on the subject) useful.
Shane,
Man, thanks so much for reading these! For a UML tool I actually use Visio with this stencil: http://softwarestencils.com/uml/index.html. There are a lot of UML tools out there, but it’s the only one I’ve been consistently happy with (odd, in that it’s visio and I generally don’t like visio). I’ll definitely check out lucid chart, the real time collaboration part sounds awesome. Anyway – thanks again for taking the time to read these – I hope you guys are doing well :).
Pingback: Step 1: In which we figure out what our software is going to do | Green Door Games
Pingback: Using OOAD to make your code more awesomer (Part 2) | Cleveland Game Developers