1

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

|improve this question
  • You need to capture all the external actions on the boundary of your system for the unit of work you are describing in your use-case. Generally, time is about the only "internal computer component" that becomes an actor. I'm sure there's some specific cases where it might be applicable but a good rule of thumb is if the computer is part of the system you are building then it isn't an actor. If you are focusing on does the computer initiate this or a user when creating your use-cases then you probably are delving into too much detail. The actor is a role not necessarily a real thing. – Dunk Oct 8 '14 at 21:36
  • @Dunk I modified my question to better convey my purpose – Ahmad Oct 9 '14 at 7:28
  • The use-case describes the interactions on the boundaries of the system you are writing the use-case for. Use-cases have different "levels". Each "system" should have its own set of use-cases. The use-cases for each level shouldn't be combined. Thus, if the software you are writing the use-cases for does not do any of the card reader processing then those steps don't belong in your system's use-case descriptions. However, those steps would be described in the use-cases intended for the overall system. But you aren't developing the overall system so no need for them in your use-cases. – Dunk Oct 9 '14 at 15:13
  • FYI:I've found the easiest way to handle "login" type processing is to create a separate "Customer Login" use-case. Then make that a pre-requisite for the other use-cases. This reduces clutter by avoiding the extends/includes problem you had asked about in another question. That way your above use-case would simply begin with "Customer requests to withdraw money". – Dunk Oct 9 '14 at 15:17
  • FYII:I still see implementation in your use-cases. "System shows a form/Customer enters the amount/through an outlet". Those are design/implementation details. They don't belong in use-cases. "Customer requests to withdraw money" covers the form and amount. "System distributes money to customer" leaves room for design/implementation decisions but still says the same thing as "through an outlet". – Dunk Oct 9 '14 at 15:23
3

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:

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.

|improve this answer
  • I had to upvote because you essentially said the same thing as my comment that I apparently posted at the same time as your answer. Anyways, you should add one thing to your answer to make it "THE" answer. Point out that it doesn't matter if Registered User is a person, a computer, a signal or a clock. At the use-case level you don't care. So don't concern yourself with it. At design time, you are likely going to create a class that represents the RegisteredUser and that's where you'll provide the hooks for the different types of initiators to kick off the use-case action. – Dunk Oct 8 '14 at 21:46
  • Thank you, I modified my question to better say my purpose, I don't mean unimportant details but those which is done by the software and those which aren't – Ahmad Oct 9 '14 at 7:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.