If you really want to use Use Cases, you should write one from the functional point of view of the System, not the end user. Maybe something like this:
- Systems start up and zeros exit their totals and counts.
- The system receives the number.
- It adds a number to the total and increments the counter.
- Steps 2 and 3 are repeated until the system is stopped.
- When said to stop the system, divides the total by a counter and returns the result.
Read Alastair Cockburn’s excellent book, Writing Effective Use Cases . It explains the existence of different levels of use. Your initial example will be considered as an example of using a user (or blue), while the steps described above will be part of an example of using a subfunction (or indigo) (it is so simple that it can even be classified as draft use and simply merged into its parent. )
As other people say, sometimes an example of use is not the best way to describe the algorithm, and you should go back to the old old flowcharts, state diagrams, sequence diagrams or the like. These tools exist for your benefit - do not limit yourself by forcing a specific method when it does not work for you.
EDIT
@devoured elysium: In response to your comments, I added a few more notes below:
When you sometimes identify domain objects, you need to think about unwritten objects. It all depends on how it was written. So, in the example that you gave, perhaps “System” is “Calculator”, the variable used to add numbers up is “Battery”, maybe there is a “Queue” that gets the number. Maybe the number itself is an object of type Number, if it can have different behavior, such as checking a range or checking the syntax of an input. Is there a "Display" object that you need to consider?
It depends on what you think in the limited context you are dealing with. Perhaps, from the User’s point of view, there is one context that simply refers to “Calculators”, but in the System’s point of view there is another that speaks of a lower lever context with “Batteries”, “ALU”, “Bits”, “Words”, “Registers "," Clock "," Latch ", etc. The further you go to the Use Case hierarchy, asking "How?" all the more technical language will become. You need to decide which domain objects and which are the objects of implementation, and this very much depends on the type of thing you are trying to describe and build (and, to a large extent, for your audience) - the ubiquitous langauge and all that!). Conversely, you can go upstairs by asking “Why?”. function is performed.
The main actor in the case of using a subfunction is, as a rule, the same actor as in the case of using a higher level that calls him. However, for some “technical” use cases, the main actor will be a system component / subtype. For example, in the system message log “Use of Case”, the calling subsystem can be named as the main actor, i.e. An object that needs / needs to initiate an action, and not an actor performing a task that caused the need for this subsystem to be something.
In this example, where the algorithm is so simple, I would probably just introduce it into a basic use case. However, if it was used in many other uses of a higher level, I would make it standalone, so I could include it from other documents. Just a functional decomposition approach.
There are no hard and fast rules. This is the style of work that you will develop over time. As others have said, make sure you are familiar with other forms of diagrams so that you can choose the right tool for the job. Remember that although an image can be worth a thousand words, sometimes you really need these words, so don't just rely on charts.