I teach OOD&A course to some students. When I want to draw a use case diagram or write the scenario of them for a system, I don’t know should I include everything (behavior) which is done in the system by human or computer or just focus on those which is done by computer.
I think Use case diagram is a tool to analyze the behavior of any system, it could be even an automobile
But when we intend to implement a system by a computer which behaviors should be considered?
if we take into account anything could be done in the system even manually by human or automatically by the computer then how and when we can extract the behavior of the software system we intend to implement
For example suppose we want to make a software for an ATM (Automated Teller Machine):
A clerk can open the ATM and put money in it. (It’s done manually, should it be considered a use case of system?)
Suppose one use case of the system is withdraw money, a scenario for it could be:
- Customer insert his card into the card reader
- Card reader validate the card
- Customer Insert his password
- System identify the customer and register him
- Customer request money withdrawal
- System shows a form
- Customer enters the amount
- System check the customer bank account and update the balance
- System delivers the money through an outlet
The cases 1 and 2 are done by card reader and not our software, should we consider them?
Or the last cases are done by the dispensing mechanism and not our software
6
A Use Case defines the interactions between an actor and a system. The actor can be a person, another system, or a clock.
More specifically, in a use case the actor refers to a particular role. So the behaviors that should be considered are those behaviors that are consistent with the role represented by the actor symbol in the diagram, not necessarily every action that such an actor can take.
To put it more plainly, pulling the plug out of the wall is not an action you need to be concerned with (although it might play a part in some problem mitigation strategy or physical security scenario). Rather, the actions you need to be concerned about are those actions which a particular role is concerned with, and the manner in which the system responds to those actions.
A very simple use case example:
Which means “In the role of Registered User, this actor can perform the system action of editing an article.”
The idea of collecting these use cases is (in large part) to identify all of the relevant user interactions and system responses, which will give you an overall idea of system scope, and provide a starting point for developing software requirements.
2