Identify actors to use

Question

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

The system that I create is an ERP system and includes a catalog to, a product catalog, a sales database, a sales journal (similar to the database, but used for accounting), a printer, a payment partner, and a shopping cart (basket).

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

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

I have two questions.

1) Will it be a precedent to sell a bunch of products to a customer in one case with the name “sell goods by” or will it be divided into several, for example, “add goods to the basket” and “full sale” (which will write a sales magazine and print a receipt) .

2) Although I program a catalog, a sales database, a sales journal, a basket, etc., can I model them as participants in my use cases? Or are the seller's only actors and payment partner?

Answer 1

Case studies are deceptively simple, but this question presents some of the inherent complexity.

Each use case should make sense to the participants involved in the sense that it should be a clearly defined interaction with the system. Each actor and precedent should also make sense when you talk about the system, even using a common language. If you are having difficulty identifying participants or use cases, then the system context is probably unclear, and so a domain model can help.

The use case should be a clearly defined interaction, but not necessarily complete. The connection <<include>> can be used in situations where it makes sense to consider both options for using full and partial interaction at the same level. For example, you can use the buy stuff include browse products , add product to cart and check out <<xor>> cancel example, each of which makes sense to the client.

(I'm a little confused about whether your system is designed for physical or online transactions; having prepress and print receipts seems to imply the first, a shopping cart as part of the concepts used in the analysis; the above assumes an on-line system.)

In your case, however, you are talking about actors who can be considered part of the system itself. Usually this means that you are trying to simultaneously determine the system and its subsystems, which is common in situations where you have a good idea (possible) to design the system before starting the analysis.

What you want to do is divide the analysis into two levels. At the top (system) level, be very strict regarding the processing of the system as a whole. In your case, you probably need the actors customer , payment partner , clerk (for a system with physical transactions), accountant (and possibly administrator ), and use the cases listed above, plus update product catalogue , audit sales log , etc. d.

Then you divide the system into subsystems and do a separate analysis for each of them. Here, subsystems can be subjects in cases of using each other. Print receipt , for example, is not a significant use case at the system level, since it alone is not an interaction between the system as a whole and the system level entity, but it makes sense as a use case for the printer subsystem, with an actor as an actor.

You do not need to complete the analysis of the system level before starting the breakdown of the subsystem, in fact, I think that it is better to have them at the same time, although this imposes higher requirements on the analyst / designer who can quickly switch contexts and be disciplined as to what context you are working at any given time.

So, after all this (yuck!), I think the answer to your questions is:

• Both, provided that each precedent makes sense to its participants as a clearly defined (but not necessarily complete) interaction with the system.
• 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 participants in cases of using each other.

Answer 2

I think you need to step back a bit first. The purpose of the Actors and Use Cases is to first ask: "Who will use this system?" and "why should they use this?" You might start to identify up, printer, etc. As Actors - and indeed, some of them may be - but there is a danger that you will miss a key point.

From your description, I would suggest that Actors and their Use Cases would have the following lines:

• Actor: Client
  • Primary use: purchase of the product. This will probably be broken down into several sub-steps, for example. Browse / Compare products, Select product (place in basket), Place an order, etc. UC will also be supported: Check the status of the order, return the goods, file a complaint, etc.
• Actor: Account
  • Use Cases: it is possible to do something with checking the status of the order / payment.

... etc..

When you start designing a thread for each UC, you will most likely identify other components external to your system that you need to interact with - for example. payment partner. You can show them as Actors if you want (my preference is not, but this is purely personal).

You also identify other elements of your system that will play a role in the implementation of UC behavior (for example, db sales, etc.). They are part of your system - and usually will not be shown as Actors.

So, in short: "Use cases" are intended to help you determine the purpose of the system and who gets value from it, and not to structure the internal components of the design.

NTN.

Answer 3

First, don’t think in terms of programming for now. Think about what business needs.

The client needs:

• Find a directory
• Add product to cart
• order

The system needs:

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

The first list will be your high-level use case, and the second will either be part of these high-level use cases, or it will include. I use include if this part of the use case is complex enough (or just long enough) to guarantee its use in my own use case. Hide complexity, as it were.

As for the catalog, sales database, sales magazine, basket, etc., the actors - participants interact with systems (or precedents). It’s hard for me to imagine how a directory interacts with something. On the other hand, the Client definitely interacts with the catalog.

An actor must be viable in the real world. If the system represents something in the real world, the system may be an actor. But in the real world, the directory is inert; the basket is inert. Sales and sales db are paper documents that are inert. These are objects, not actors.

BTW - is the seller of the system?

Answer 4

Use cases are not absolute. You might have a vague usage example, such as Manage Users (I'm not sure that managed cases are good practice, but this is for the sake of example ...) in the first sketch of your system, and then break it down into more detailed use case diagrams that improve situation until you come to the main function.

As for your second question, they sound like typical domain objects (which should be modeled as a basic class diagram). I do not think that they should be modeled as actors if they do not play an active role. Actors will be physical people, but also other systems that interact with the system being created. These Actors may turn out to be the so-called subtitle classes.

Update

Looking through the article linked above , it seems that the actor (a synonym for the player) is used to determine the target to which the role belongs. If this is correct, then the word has a different meaning.

A role is a special kind of object that adds behavior to another object (actor or player)

Answer 5

without reading the other answers: - / here are mine:

1) Will it be a precedent to sell a bunch of products to a customer in one case with the name “sell goods by” or will it be divided into several, for example, “add goods to the basket” and “full sale” (which will write a sales magazine and print a receipt) .

I always try to use the use case as "interacting with a system that brings value to the actor." "sell goods" will make a difference. "add product to cart" will not matter.

I wrote “I'm trying,” because often you start with good use cases that follow my definition, but then you start adding details and expanding your use cases ...

2) Although I program a catalog, a sales database, a sales journal, a basket, etc., can I model them as participants in my use cases? Or are the seller's only actors and payment partner?

I use actors not only for real people, but also for systems that interact with your system. But the terms "database", "log", etc. They tell me that it looks like you want to add too many details to your chart.

Maybe a good aproach is to first think about the reason for creating a usage chart.

For me in most cases the reason is that I would like to get a first impression of which system I need to build. Then I use the chart as a tool for a moderate meeting. This helps to find answers to the following three questions:

• who will use the system?
• What will these actors do with the system?
• What other systems interact with the new system?

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