Identifying Actors for Use Cases

Question

I am working on a little hobby project and am experimenting with doing things a little differently.

The system I am building is an ERP system, and includes a till, product catalogue, sales database, sales log (similar to the database, but used for accounting purposes), a printer, a payment partner and a basket (cart).

Although the printer is hardware, I need to program the higher level code to print receipts.

The only part which I do not need to program is the payment partner.

I have two questions.

1) Would the use case to sell a bunch of products to a customer be one use case named "sell items at till", or would be be broken into several, such as "add product to cart" and "complete sale" (which would write the sales log and print the receipt).

2) Although I am programming the catalogue, sales database, sales log, basket, etc, can I model them as actors in my use cases? Or are the only actors the sales person, and the payment partner?

Answer 1

Use case analysis is deceptively simple, but this question betrays some of the inherent complexity.

Each use case must be meaningful to the actors involved, in the sense that it must represent a well-defined interaction with the system. Each actor and use case must also make sense when you talk about the system, even using everyday language. If you find yourself in difficulty defining either actors or use cases, then probably the system context is unclear and so a domain model might help.

A use case must represent a well-defined interaction, but not necessarily a complete one. The <<include>> relationship can be used in situations where it makes sense to see both full- and partial-interaction use cases at the same level. You might consider having a use case buy stuff include browse products , add product to cart and check out <<xor>> cancel , for instance, each of which makes sense to the customer.

(I am a little bit confused about whether your system is intended for physical or on-line transactions; having a till and printed receipts seems to imply the former, a shopping cart as part of the concepts used in the analysis the latter. The above assumes an on-line system.)

In your case, however, you are talking about actors which may be considered part of the system itself. This usually means that you are trying to define the system and its subsystems at the same time, which is common in situations where you have a good idea of the (eventual) system design before you start the analysis.

What you want to do then is to split the analysis into two levels. At the upper (system) level, be very strict about treating the system as a whole. In your case, you'd probably need the actors customer , payment partner , clerk (for a physical-transaction system), accountant (and maybe administrator ), and use cases as listed above plus update product catalogue , audit sales log , etc.

Then you break the system down into subsystems and do a separate analysis for each of them. Here the subsystems can be actors in each others' use cases. Print receipt , for instance, is not a meaningful use case on the system level because it is not in itself an interaction between the system as a whole and a system-level actor, but it is meaningful as a use case for the printer subsystem, with the till as the actor.

You do not need to complete the system-level analysis before you start the subsystem breakdown, in fact I think it's better to have them both active at the same time - although this places higher requirements on you the analyst / designer to be able to switch contexts quickly and be disciplined about which context you're working in at any given time.

So, after all that (phew!) I think the answer to your questions are:

1. Both, provided each use case makes sense to its actors as a well-defined (but not necessarily complete) interaction with the system.
2. Yes, but not at the same level; with one model for the system and separate models for each subsystem you can use the subsystems as actors in each others' use cases.

Answer 2

I think you need to step back a little first. The purpose of Actors & Use Cases is to first ask: "who will use this system?" and "why will they use it?". You could start identifying till, printer, etc. as Actors - and indeed, some of them may be - but there's a danger you'll miss the key point.

From your description, I'd guess the Actors and their Use Cases would be along the following lines:

• Actor: Customer
  • Primary Use Case: Buy Product. This will likely break down into a few sub steps, eg Browse/Compare Products, Select Product(s) (place in shopping basket), Checkout, etc. There will also be supporting UCs: Check status of order, return goods, make complaint, etc.
• Actor: Accounts Clerk
  • Use Cases: presumably something to do with checking order/payment status

...etc.

When you come to designing the flow for each UC you will likely identify other components external to your system with which you need to interact - eg payment partner. You can show these as Actors if you wish (my preference is not, but that's purely personal).

You'll also identify other elements of your system that play a role in realising the UC behaviour (eg sales db etc). These are part of your system - and wouldn't typically be shown as Actors.

So in summary: Use Cases are meant to help you identify the purpose of the system and who receives value from it - rather than structure the internal design components.

hth.

Answer 3

First, don't think in terms of programming at this point. Think about what the business need is.

The customer needs to:

• Bowse the catalog
• Add an item to the shopping cart
• Checkout

The system needs to:

• Display the requested product
• Complete the sale (or not)
• Collect the payment
• Generate a sales receipt for the customer
• Deliver the purchased product

The first list would be your high-level use cases and the second would either be part of those high-level use cases or be includes. I use includes if that part of the use case is complex enough (or just plain lengthy enough) to warrant putting it into its own use case. Hide the complexity, as it were.

As far as the catalog, sales database, sales log, basket, etc. being actors - actors interact with systems (or use cases). I'm having a hard time imagining a catalog interacting with something. On the other hand, the Customer definitely interacts with the catalog.

An actor has to be viable in the real world. If a system represents something in the real world, a system can be an actor. But in the real world, a catalog is inert; a basket is inert. A sales log and sales db represent paper records - which are inert. They're objects not actors.

BTW - is the Sales Person the system?

Answer 4

Use cases aren't absolute. You can have a vague use case such as Manage Users (I'm not sure Managed cases are a good practice but this is for the sake of an example...) in a first sketch of your system and then break it down into more detailed use case diagrams refining things along the way until you come down to a basic feature.

As for your second question, these sound like typical domain objects (to be modelled as a basic class diagram). I don't think they should be modelled as Actors unless they play an active role. Actors would be physical people but also other systems that interact with the system you're creating. These Actors will possibly end up as so-called subtitute classes.

Update

Going through the article linked above it appears that actor (synonymous with player) is used to qualify the target object to which a Role is being added. If this is the correct than the word has a different meaning.

A Role is a special kind of object that adds behaviour to another object (the actor or player)

Answer 5

without having read the other answers :-/ here are mine:

1) Would the use case to sell a bunch of products to a customer be one use case named "sell items at till", or would be be broken into several, such as "add product to cart" and "complete sale" (which would write the sales log and print the receipt).

I always try to use a use case as "an interaction with the system which brings a value to the actor". "sell item" will have a value. "add product to cart" will have no value.

I wrote "I try to", because often you start with good use cases which follow my definition, but then you start to add detail and extend your use cases...

2) Although I am programming the catalogue, sales database, sales log, basket, etc, can I model them as actors in my use cases? Or are the only actors the sales person, and the payment partner?

I use actors not only for real persons, but also for systems which interact with your system. But the terms "database", "log" etc. tell me that it seems you want to put too much detail into your diagram.

Maybe a good aproach is to first think about the reason for creating a use case diagram.

For me, most of the time the reason is that I would like to get a first impression on what kind of system I have to build. I then use the diagram as a tool to moderate a meeting. It helps to find answers to the following three questions:

• who will use the system?
• what will those actors do with the system?
• which other systems are interfacing with the new system?

And that's all. When it goes into more detail, I use a different set of diagrams.