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 3: in which we discover that our feature list sucks) we employed the first of our Analysis Superpowers by checking our feature list against our use case diagram to see if we had anything missing (which we definitely did). Now that we’ve got that problem solved, it’s time to learn a new Analysis Superpower!
Analysis Superpower 002: Magically transforming big software problems into smaller, more manageable ones!
So, now we have this big list of features and use cases; and we have some idea how they all relate to each other. At this point you might be wondering what to work on first. It’s important when making this decision that you choose parts that are well encapsulated, so your team (even if it’s just you) can work as independently as possible. You also always want to focus on the riskiest, least understood items before focusing on the ones you know well. There are essentially two steps involved in making this happen, the first of which is called System Analysis (we’ll cover the second one in the next article).
The totally kick ass world of System Analysis:
System Analysis is where you take your use cases and features and group them into logical categories or systems. For instance, the use case/features listed below were paired together during our last step:
(UC008): Application handles player and game status information.
(Woebot-F002): The game shall provide a time based scoring system – the faster you finish the game, the higher your score.
(Woebot-F004): The player shall posses a health meter which can be reduced by taking damage or increased by collecting health units.
From comparing and contrasting the relationships above we could categorize all three of these items under one system. A system name should describe the responsibility of that system as briefly and succinctly as possible, so we’ll call this one “Status Update System”. So, by putting that use case and it’s features under one name we’ve created a small, well encapsulated section of the project that can be worked on fairly independently. It also has the benefit of describing a few different behaviors with only a few words. This is going to come in very handy later when we talk about our third Analysis Superpower, but in the meantime let’s go through the rest of our features and use cases and see if we can fit them into categories too.
How not to do System Analysis:
In the diagram below I’ve laid out our use cases/features, and grouped them into multiple arrow boxes pointing to a system they might belong to. Obviously, since this is the “How not to” section, I’ve done something wrong.
If you create a system for each set of use cases and features you’re likely to end up with a lot of systems. The problem with breaking things up this way is that it doesn’t make the solution any easier to manage. Not only are there too many chunks, but they share a lot of common behavior, which doesn’t really make sense. Let’s look at a different way to lay these out…
A better way to do System Analysis:
What we need to do is combine some of the common elements from our previous diagram to create as few systems as possible, each carrying out a single major responsibility.
So, now everything is organized into logical chunks. More importantly we’ve identified parts of our software that can be encapsulated from other parts. In other words all any system needs to know about another system is what it does, and not how it gets done. For instance, the Game Engine system shouldn’t care whether character input comes from a mouse, joystick, keyboard, or some kind of monster AI – it should all work the same way. Likewise, the weapon system should be able to handle targeting, shooting, upgrades, and other weapon behavior regardless of what character fires a weapon (for instance, maybe there are bad guys who will use the same kind of weapon as the player). In addition, any classes in a system should be able to handle change without breaking code in the other systems (we’ll get to classes in another article).
You’ll also notice that I added two more use cases in this step that I hadn’t thought of before. Again, one of the most important parts of this process is that it helps you think through what your software is going to do. That way you don’t realize you have to make a bunch of changes once code is written. I’ve added what we did today to our Woebot Chapter 1: Design Document, please feel free to review it.
So, that’s it for this post! Now the project is separated into manageable chunks that should operate independently from each other. Next time in Step 5: In which we build of tower from things we should be worried about we’ll learn our third analysis super power! Thanks again for reading, and I’d love to hear any feedback you might have!