• Nu S-Au Găsit Rezultate

The UML 2 Functional Modeling of a Cash Register Simplified System. Case Study

N/A
N/A
Protected

Academic year: 2022

Share "The UML 2 Functional Modeling of a Cash Register Simplified System. Case Study"

Copied!
10
0
0

Text complet

(1)

Cycle: UML FOR MANAGERS (III)

The UML 2 Functional Modeling of a Cash Register Simplified System. Case Study

Gabriel Irinel Marcu, Liviu Dumitraşcu

Universitatea Petrol-Gaze din Ploieşti, Bd. Bucureşti 39, Ploieşti email: [email protected], [email protected]

Abstract

This paper presents an original case study which creates the functional model of a simplified system for the use of a cash register (CRS) in a supermarket. The following stages are accomplished: the identification of the actors and of the use cases; the construction of the use case diagram; the organization of the use cases; the graphic representation of the use case diagram; the (essential, real) description of the use cases with narrative text.

Key-words: actor, use case, use case diagram, inclusion, extension, generalization, essential description, real description, sequence diagram

Problem Formulation

The functioning of a cash register in a supermarket can be described as follows: the client reaches the cash register with the products he/she wants to buy. The shop assistant registers the identification code for each product as well as the quantity if that is more than 1.

The cash register displays the following information: code; product name; unitary price;

quantity; overall price.

Optionally, the shop assistant can modify the quantity or can delete a product if the client does not want to buy it anymore.

The client can opt for one the following payment alternatives: cash/card/ coupons.

If the selling is accepted, then the shop assistant validates the selling, prints the bill of sales which he then passes to the client. If not, the selling is cancelled.

Requirements

Starting from the presented elements, create the functional model for cash register simplified system (CRS) going through the following stages:

1. identifying the actors;

2. identifying the use cases;

3. constructing the use case diagram;

(2)

4. organising the use cases;

5. representing the use case diagram using one of the UML software tools;

6. describing the use cases.

Stage 1 - Identifying the CRS Actors

The Actors

A first actor that can be identified is the shop assistant (cashier). He/she directly uses the cash register, he registers the identification code for each product and, optionally, he/ she can change the number of products (quantity) that the client wants to purchase.

On the other hand, the shop assistant cashes the value of the products and he finally issues the bill of sales.

As a consequence, the cashier is a main CRS actor.

The second actor that can also be easily identified is the actual client. The client is the (secondary) actor who benefits from the using of the cash register.

Remark:The client’s card, the cash register and the cash swipe device are part of CRS but cannot be considered actors. They are merely peripheral materials.

Another actor, this time non-human, but who takes active part in the product identification is the external system: Product Manager, being considered a secondary actor. The actor Product Managerhas also the role of registering all the information regarding the sold products in a data base, but only after the client has paid for them.

The Actors’ Graphic Representation

For the graphic representation of the human actors (cashier, client) use the stick man icon by placing the actor’s name under the icon (figure 1).

Figure 1

For the graphic representation of the non-human actors (Product Manager) use the standard graphic representation- a square containing the key-word “actor” and the actor’s name (figure 1) For the system representation (CRS) draw a square and place CRS within it (figure 1).

Try as much as possible to place the main actors on the left side of the square thus delimiting the frontiers of the system (CRS) and place the secondary actors on the right side (figure 1).

(3)

Stage 2 - Identifying the Use Cases

Use Case/ Actor

We shall further on present the way in which CRS is used by the three actors identified in the previous stage.

The cashier (main actor) takes part in the following use cases: authentication; sales bill issuing.

The client (secondary actor) takes part in the use case: sales bill issuing

Products management (secondary, non-human actor) takes part in the following use cases:

searching for the product; authentication.

Stage 3 - Building the Use Case Diagram

The Use Case Diagram

For the graphic representation of a use case use the symbol ellipsis. The name of the use case can be included in the ellipsis or underneath it.

Connect the use cases and the actors by means of lines which represent the association relationship.

Figure 2 presents the preliminary diagram of the use cases identified in the previous stage.

Figure 2

Remark: The connection with the (secondary) actor Products Manager is a unidirectional association represented by means of a navigability arrow (→). The actor Products Manager receives messages without emitting them (only receptor actor!).

Stage 4 - Use Case Organisation Inclusion

Use the standard representation of the inclusion relation: the key-word “includes” and a discontinuous arrow in order to represent the inclusion-type dependency relation between the

(4)

use case “Issue Bill” and the use cases: “Search for Products ”; “Perform payment”; “Cancel Sales”; “Validate Sales ”.

Figure 3 presents the completed use case diagram with all the use cases included in the Issue bill of sales.

Figure 3

Extension

Use the standard representation of the extension relation: key-word “extend” and a discontinuous line arrowed in order to represent the extension-type dependency relation between the use cases “Issue Bill ” and “Purchase Promotional Products”.

Figure 4 presents the use case diagram completed with the use case “Purchase Promotional Products” which extends the use case “Issue Bill ” if the condition ‘the client has purchased promotional products’ has been accomplished.

Figure 4

(5)

Remarks:The two use cases: “Issue Bill” and “Purchase Promotional Products” can be executed independently but equally the case “Purchase Promotional Products” can be intermingled within the case “Issue Bill”-extension point Promo must be declassified in the description with narrative text of the use case “Issue Bill”.

Generalization/ Specialization within Use Cases

The use case “Perform Payment” is a generalized use case. It presents the particularity of being abstract because it cannot be instantiated directly, but only by means of the three specialized cases: Pay by Cash ; Pay by Card; Pay by Ticket.

Figure 5 displays the use case “Perform payment” where we have used the standard graphic representation of the generalization relation.

Figure 5

Stage 5 - Representing the Use Case Diagram Using UML Tools

Figure 6 presents the final diagram of the use cases automatically constructed by means of the UML software product Poseidon.

Figure 6

(6)

Remark:UML software product Poseidon represents an integrant part in the category of multipurpose UML software tools.

Stage 6 - Describing the Use Cases

Because of space reasons, we shall further on describe only the use case “Issue Bill” in two variants: with narrative text and graphically.

Narrative Text Description

The description of the use case “Issue bill” will be accomplished from an analytical point of view (essential use case) and from a conceptual point of view (real use case).

Essential Description

The essential description is used if we wish an independent from the working/software environment case description. [1]

Figure 7 displays theessential description of the use case “Issue Bill”.

Figure 7 Identification

Case name Issue Bill

Main Actor Cashier

Objective Records the sales of the clients get the money from the clients Preconditions the cash register is in use

Postcondition The sales were recorded by cash register

The nominal scenario

1 This use case starts when one client reaches the cash register together with the products wich the client wants to buy

2 The cashier types the product identification code for each product;

3 The cash register system searches for product code, determines the unitary price for each product, adds the information defining the respective product and afterwards displays the price of the product and the overall price;

4 After registering the last product, the cashier tells the customer the overall amount that he has to pay;

5 The client chooses the payment method and pays for the products 6 The cashier give the bill to the client

7 The client leaves the supermarket with the products bought

Alternative scenario

3. a The product identification code is unknown

1. the cash register system displays an error message " The product can not be registered".

The scenario go on with the step 2 of nominal scenario if the client has bought other products or with step 6 if not

3. b There are more than one item per product 1. the cashier changes the quantity;

2. the cash register system display the new value, then the price of the product and the overall price and the scenario continues with the step 2 of nominal scenario

3. c The client give up a product

1. the cashier deletes the registered product

2. cash register system update the display and the overall amount and the scenario continues with the step 2 of nominal scenario

3. d The client wish to purchases the promotional products

1. the cashier identify the promotional products and the scenario go to extension point

"Purchase promotional products"

5. a The client choose the the payment by cash 1. go to "Pay by Cash" use case 5. b The client choose the the payment by card

1. go to "Pay by Card" use case

(7)

2.

5. c The client choose the the payment by cash 1. go to "Pay by Ticket" use case

Real Description

Real description presents the case in terms of events, user interface, etc. [1]

Figure 8 presents the human-machine interface (HMI) of the cash register in 4 different stages.

Figure 8

Figure 9 displays the real description of the use case “Issue Bill”.

Figure 9 Identification

Case name Issue Bill

Main Actor Cashier

Objective Records the sales of the clients get the money from the clients Preconditions the cash register is in use

Postcondition The sales were recorded by cash register

The nominal scenario

1 This use case starts when one client reaches the cash register together with the products wich the client wants to buy

(8)

2 The cashier types the product identification code for each product;

3 The cash register system searches for product code, determines the unitary price for each product, and dispays the characteristic information defining the respective product: code in the field Code, product name in the field Name, quantity in the field Quantity and unitary price in the field Price. Also, he compute and display the overall price;

4. The cashier modify the quantity if there is more than one items per product

5 Cash register system validate the quantity displaying the new quntity and updating the overall price

6 The cashier delete one product on client command selecting in table the appropiate line and pressing the Delete button

7 Cash register display the updated list of products and recalculate the overall price

8 The cashier tells to the client the overall amount that he has to pay;

9 The client chooses the payment method and the cashier press the "Cash Payment"

button if the client wants to pay by cash,

"Card Payment" button if he wants to pay by card or "Ticket Payment" if he wants to pay by ticket

10 The Cash Register System wait for payment

11 The cashier press the "Validate" button if the payment was accepted or press the

"Cancel" button if the payment was invalid

12 Cash Register System records the selling and print the bill or cancel the selling displaying an error message

13 Cash Register System starts a new tranzaction, filling with empty spaces the input fields

14 The cashier give the bill to the client The client client leaves the supermarket with the products bought

Graphic Description

We shall further on complete the narrative text description of the use case “Issue Bill" by means of a UML dynamic diagram: system sequence diagram.

The sequence diagram is used primarily to show the interactions (incoming and outgoing messages ) between objects in the sequential order that those interactions occur.

The UML sequence diagrams model the flow of logic within the studied system in a visual manner, enabling to software developers both to document and validate their logic.

Figure 10 displays the system sequence diagram (SSD) for the description of the nominal scenario of the use case “Issue Bill”.

(9)

Figure 10

References

1. R o q u e s , P. -Memento UML, Eyrolles, 2006

2. R o q u e s , P. -UML 2 par la pratique, 5-e édition, Eyrolles, 2006

(10)

Ciclul: UML PENTRU MANAGERI (III)

Modelarea funcţională a unui sistem simplificat de utilizare a unei case de marcat cu UML 2. Studiu de caz

Rezumat

În acest articol se prezintă un studiu de caz original în care se creează modelul funcţional al unui sistem simplificat de utilizare a unei case de marcat (SCM) dintr-un supermarket. Se parcurg următoarele etape: identificarea actorilor şi a cazurilor de utilizare; construirea diagramei cazurilor de utilizare;

organizarea cazurilor de utilizare; reprezentarea grafică a diagramei cazurilor de utilizare; descrierea (esenţială, reală) a cazurilor de utilizare cu text narativ.

Referințe

DOCUMENTE SIMILARE

Abstract: The Canadian Immigration and Refugee Protection Act provides that one of the objectives of immigration is “to see that families are reunited in Canada.” The Act

Form the analysis of the depositions of the Regulation, it results that a court in Romania invested with a request (main or ancillary) relating to parental

Keywords: trickster discourse, meaning, blasphemy, social change, transgression of social norms.. The Myth of the trickster and its

In particular, there exist a number of properties setting EDs aside from other HDs: EDs are ‘non-actantial’ datives, since they are not part of the valency of the verb but have

I will only tackle the first level of analysis, in other words the information displayed on the cover, and the strategic pages of two of the RR issues which

The evolution to globalization has been facilitated and amplified by a series of factors: capitals movements arising from the need of covering the external

m3 and a surface of 75 ha which would supply with drinkable water the resorts Azuga, Bu şteni, Sinaia, Comarnic and Breaza used also to produce the electric energy for

We then go on to examine a number of prototype techniques proposed for engineering agent systems, including methodologies for agent-oriented analysis and design, formal