4. Chart of use cases

The system behavior (i.e., the functionality it provides) is described using a functional model that displays system use cases (use cases, use cases), system environment (actors, actors, actors) and the relationships between them (use cases diagrams) .

A use case diagram (use case diagram, use case diagram) is a diagram that depicts the relationship between actors and use cases.

With this chart you can:

• Determine the general boundaries and context of the modeled domain in the initial stages of system design;

• Formulate general requirements for the functional behavior of the designed system;

• Develop the initial conceptual model of the system for its subsequent detailing in the form of logical and physical models;

 Prepare initial documentation for interaction of system developers with its customers and users.

The use case (use case) diagram is

a graph in which the actors or precedents are located at the vertices, the connections between the vertices are a different kind of relationship.

An actor (actor, actor) is any object,

the subject or system interacting with the simulated system from the outside. This may be a person, a technical device, a program or

any other system that serves as a source of impact on the simulated system as determined by the developer. In the use case diagrams, an actor is depicted as a little man, under which his name is recorded (Fig. 8).

Figure 8. Actor (actor)

A use case (use case) is a description of a set of a sequence of actions (including options) performed by the system so that an actor can get a certain result [1].

Each use case should be independent in the sense that if it is always executed in conjunction with another use case, then most likely it is one precedent, not two, or they are related by the inclusion or extension relation, which will be discussed later. As follows from the definition, a precedent (or use case) must have a resultant value for an actor, an actor must get some result from the execution of a precedent. Most likely, after the execution of the precedent, some changes will occur in the system: new data will appear, behavior will change. Each use case must be executed from start to finish.

The precedent describes what the system does, but does not specify in any way how it does. Note that the use case diagram does not display the sequence in which use cases will be executed. In the diagram, the precedent is depicted as an ellipse. The use case name may consist of several words and punctuation marks (with the exception of

colon), as a rule, the name is chosen in the form of a phrase or a verbal expression (Fig. 9).

Figure 9. Use cases (use cases)

One of the most important (and expensive) stages of information systems design is the stage of determining system requirements. If the requirements of the customer of the information system are determined incorrectly by the developers, then as a result the customer may receive a completely different system than he expected.

Modeling use cases and actors helps us better understand the requirements for the system and coordinate them with the customer through the demonstration and discussion of the use case diagram. Precedents and actors are a reflection of system requirements, they show who will use the future system and for what.

Example. Define the actors and precedents of the store's order system

"Style".

Recall that the buyer places an order, putting the goods in the basket. Only one form of payment is possible: by credit card over the Internet, it is impossible to place an order without payment. The order has the status: paid, transferred to a complete set, assembled, received. Order status is changed automatically or by an employee of the store. The buyer can find out the status of his order by unique order number.

The system does not deliver goods to the store. This is done by another system, let's call it Warehouse.

Thus, the buyer, the store employees and the external Warehouse system interact with our system. With our system, an employee of the sales department interacts, who checks the payment of the order and sends it for a complete set, and the storekeeper, who collects the order and issues it to the buyer. From a business point of view, these are two different positions that perform different functions, but from a system point of view, they play one employee role changing customer order status using the software of the simulated system. In this sense, there is no difference for a system between a sales person and a stockman. When choosing actors, you need to remember that we must reflect their role, and not the position. We introduce a summary of the employee acting person - Employee. Another example: an employee of a Style store (we assume

storekeeper) can act as an employee and communicate with the system as an employee of the store, and can also act as a buyer by placing an order in the store. Despite the fact that physically this is one person, he acts as two actors: the buyer and the employee. So, the actors of the order system of the Style shop will be the following:

Buyer, Employee, System Warehouse.

The buyer uses our system to order things, he looks through the catalog, adds the goods he likes to the basket, opens the basket, deletes the goods from it or changes their quantity and, finally, can place his order, while paying for it. In the end, the result of the use of the system by the buyer will be obtained if he performed all these actions from start to finish. Therefore, we will not divide the order of goods into several precedents, but select only one: Order of goods.

The buyer, having made an order in the “Style” shop, can further find out the status of his order, this is also a case of using the system,

call it Getting Order Information.

The employee must change the status of the order, for him we define a precedent Manage order status.

The Warehouse system should receive information about the orders made in order to control the availability of goods in the warehouse; a precedent for receiving information about the order should also be available to it.

So, the precedents of the order system of the shop "Style": Order goods,

Order status management; Getting order information.