I am a bit confused about where to describe the algorithm I might use in some part of an application.
Let’s say I want to create a Use Case that describes how the User inputs a set of values and my application returns the average of those values (of course this is a dead-easy case, but its easier to explain it this way).
1. The User tells the System he wants to calculate the average of a set of numbers.
2. The System asks the User for a number.
3. The User tells the System a number.
Repeat steps 2-3 until the User tells the System there are no more numbers left.
4. The System returns the average of all those numbers.
Now, where should I state the algorithm behind calculating the average of the numbers?
What if instead of calculating the average of numbers, I had to change the configuration of a game, go to the next level, add users to a database given a set of conditions, etc?
I feel like I need to in some way formalize the knowledge I have of the domain, otherwise I might either forget it or even worse, assume I know things that only by writing down would I understand I don’t.
In other thread, topic, someone talked about business rules. From what I’ve read they seem to be put as small notes on class diagrams. Maybe I’m wrong? If that’s what they are, I find they too cumbersome to use for more complex algorithms.
Thanks
If you really want to stick with Use Cases you’d write one from the System’s functional viewpoint rather than that of the end-user. Maybe something like this:
Have a read of Alastair Cockburns excellent book “Writing Effective Use Cases“. It explains about having different levels of Use Case. Your initial example would be considered a User Goal (or Blue) Use Case whilst the steps above would be part of a Sub-Function (or Indigo) Use Case (it’s so simple it might even be classed as a Black Use Case and just merged into its parent).
As other people are sure to say, sometimes a Use Case isn’t the best way to describe an algorithm and you should fall back to good old flowcharts, state charts, sequence diagrams or whatever. These tools are there for your benefit – don’t be constrained by forcing a particular method when it doesn’t work for you.
EDIT
@devoured elysium: In response to your comments I’ve added a few more notes below:
When you’re identifying domain objects sometimes you need to think about unwritten objects. It all depends on how it has been written. So, in the example you gave, maybe the “System” is a “Calculator”, the variable being used to add the numbers up is an “Accumulator”, maybe there’s a “Queue” that receives the number. Could be that the number itself is an object of a type “Number” if that can have distinct behaviour like range validation, or input syntax checking. Is there a “Display” object that you need to consider?
It depends on what you consider to be in the bounded context you’re dealing with. Maybe, from the User’s perspective, there is one context that just deals with “Calculators”, but the System’s viewpoint there’s another that speaks to a lower lever context with “Accumulators”, “ALUs”, “Bits”, “Words”, “Registers”, “Clocks”, “Latches”, etc. The further you go down in the Use Case heirarchy by asking “How?” the more technical the language is going to become. You need to decide which are Domain Objects and which are just Implementation Objects and that depends very much on the type of thing you’re trying to describe and build (and, to a great extent, who your audience is – ubiquitous langauge and all that!). Conversely, you can go up the stack by asking “Why?” the function is being performed.
The primary actor of a Sub-Function Use Case is generally the same actor as that of the higher-level use case that calls it. For some “technical” Use Cases though, the primary actor will be a system component/subsytem. For example, a system message logging Use Case might have the calling subsystem as the primary actor – i.e. the entity that had the will/need to initiate the action, rather than the actor that was performing the task that caused that subsytem to need to log something.
In this example, where the algorithm is so simple, I’d probably just Embed it into the main Use Case. However, if it was being used in multiple other higher-level Use Cases I’d make it Standalone so I could include it from the other documents. Just a functional decomposition approach.
There are no hard-and-fast rules with this. It’s a style of working that you’ll evolve over time. As others have said, make sure that you’re familiar with the other forms of diagrams so that you can pick the right tool for the job. Remember that although a picture may be worth a thousand words sometimes you actually need those words too so don’t just rely on diagrams.