UML: Use Case Models part 1

What are Use Case Models? First of all: They are simple visual specification of user goals at a high level.  They should be so simple that you can explain them to a manager suffering from serious attention span disorder, or a puppy.  Not all managers suffer from attention span disorder, and especially not mine, who is a kind and generous genius, especially at review time. :)  But you should get my meaning here.

When starting a use case model, it is very important to keep it simple.  The real reason is that you may need to refer to them at a later time, usually under deadline pressures or even legal reasons.

Often it is easiest to first determine the actors of the system, and then flush out the use cases that they perform. 

Your use case diagrams can be as simple or complex as you wish, however simpler, less cluttered diagrams are easier to understand, and are often more powerful in capturing the tasks of the system.  Which means: AVOID COMPLEXITY.  Stokes Theorem: You can create complexity out simplicity, but not simplicity out of complexity.  (Ok, that isn’t really Stokes Theorem, but… oh well.)

For example, the use case create account during the design or later modifications of the system, may require further specifications. 

Remember that a use case a microscopic (atomic) programming operation, it is a general case. 

Build your use cases to clarify the goals and expectations for the system’s users.

Returning to the back story:

In your proto-corporation you and your business partner had just completed a class that was heavy on UML in college, your business partner decided to work up a scenario around a game you two were working on.  You went on to take a game class from a professor like me, not all that good at showing you how to code, but good at the big picture.  Your business partner took charge of the Use Cases, in fact he owns the rights, which would be expected in a rational world.  Making intellectual rights a thread to this story as well. 

For now, we will walk through the initial use case your business partner and college buddy built. 

And it turns out now that you have need to upgrade your product, it is good thing he did.  But let’s go back to the beginning, his first thought was that the User will need to create an Account.

An actor, the gamer, is shown here as having a one to one association with “Create an Account”, I have used he drop down box to write a description of the association.  It is these descriptions that will provide you with the necessary information to determine what YOU were thinking about when you make this Use Diagram, you write these for the future, make sure you spend time doing the entries, for many people that causes a weird feeling in your brain and can be annoying, try to ignore that and do the writing.  On the other hand, some people really enjoy this, if you are one of them, KEEP UP THE GOOD WORK!  Everyone else, you have to do the descriptions.

In the next  blog we will go over how use cases combine with other use cases.