Management Environment
2.2 UML Model for a Bakery System
In this section, we introduceUML model for a bakery system. Using this model, we will clarify the general concept of UML diagrams. Additionally, model of a bakery system is the subject of the case study. Therefore, this example will help to understand the case study description and the quality assessment results described in Chapter 6.
2.2.1 Description of a Bakery System
The bakery software system handles all aspects of a bakery, including sales ordering, personal management and warehouse management of the products.
The sales ordering system handles the selling of the bakery products. Personal management system manages the personal data of the employees. The warehouse system manages the inventory of the bakery products, and it also records the expiry date of each product. The bakery sales include several kinds of breads, rolls, cakes and pastries that vary every day. Seasonal offers include various cakes according to the season, such as strawberry cakes or christmas cakes.
The external actors of the system are shown at the top of Figure2.6, where the three types of users can interact with the system. The Administrator is an actor who manages the software solutions and set privileges to the users of the system.
2.2. UML MODEL FOR A BAKERY SYSTEM 13
The external actors areSalesman andOnline Customer. Salesman interacts with the system to handle customer orders and payments at the counter, where an Online Customer uses a web based system, where they can order, modify orders and make online payments with limited access to the system. The bakery system allowsOnline Customer,Salesman, andAdministrator to access it as separate users with different privileges.
Personal Management Sales Ordering
Warehouse
Online Customer Administrator
Bakery System Actors
Salesman
Figure 2.6: General Overview of the Bakery System Components
Existing users that are eitherSalesman orOnline Customer are required to login to the system. New Online Customers are able to create a new account by registering using an online form. Once aSalesman orOnline Customer are logged in, they will be directed to the sales ordering subsystem, where they can choose which product to order. After theOnline Customers has decided the quantity of the selected item, it will be added to a cart. From the cart, the Online Customer can choose between two payments methods, either by credit card or by cash. Once the payment is successful, the order is executed by the system. Administrator can view the database, categorized into users, inventory and orders. In each category, Administrators can then perform various actions like add, edit, or delete entries.
2.2.2 Partial UML Model for the Bakery System
This section presents an overview of the diagrams used to develop the analysis model and design model for the bakery system.
2.2.2.1 Use Case Diagram
The three subsystems of the bakery software system are illustrated in Figure2.6.
In this section only theSales Ordering subsystem is discussed. A use case diagram of this subsystem is visualized in Figure 2.7. There are three actors interacting
with the subsystem: Salesman, Administrator and an Online Customer. The Salesmaninteracts with different parts of the ordering process. Salesman interacts with the use case Place Order to place an order for the customer and the use caseManage Orders to manage the customer’s orders. Online Customer interacts with the use case Place Order to place an order online and with the use case Make Payment to pay for the ordered item. Make Payment includes another use case Choose Payment, where Online Customer can choose a payment method.
Administrator interacts with the use case Manage Orders to manage customer orders and with use caseMange Customer Database to manage the customer data base.
Academic Use Only
Place Order
Make Paym ent
Chose Paym ent Method Manage Orders
Manage Custom er Database
Online Custom er Salesm an
«include»
Adm inistrator
Sales Ordering
Figure 2.7: Use Case Diagram for Sales Ordering
2.2.2.2 Activity Diagram
Activity diagram are used to document the flow within a use case [89]. The flow can be sequential, branched or concurrent. Figure 2.8 shows the activity diagram for the Make Payment and Choose Payment Method use cases. The payment cost is calculated from the cart, where the ordered bakery products and their cost are listed. After the amount is verified, the user has to select a payment method.
This functionality is provided by theChoose Payment Method use case.
2.2. UML MODEL FOR A BAKERY SYSTEM 15
activity ad2[ ad2 ]
Show Re com m e ndation
Me ss age
Validate Trans action
Generate Chose
Com pute Total Price
Add to Order DB Show Error
Me ss age
yes
card
reject
no
cash
approve Make Payment
Retrie ve Total Price from Cart
Ve rify Total Am ount
Paym e nt Type
By Cash By Credit Card
Report
Figure 2.8: Activity Diagram for Make Payment
2.2.2.3 Class Diagram
Class diagrams show the static structure of classes of a system and the relation-ships between them. The relationrelation-ships can be associations, generalizations, or aggregations. The class diagram for the Sales Ordering subsystem is illustrated in Figure 2.9. The figure shows how the different classes are associated with each other. Two types of associations are used in this diagram: composition and gener-alization. Figure 2.9illustrate following classes for the Sales Ordering subsystem:
BakerySystem, BakerySystemDB, Customer, Payment, Cart and CreditCard.
Academic Use Only
pack age Data [ CD ]
-connection1 -connection2 -query : String
+executeQuery( sql : String ) : Boolean +openDB()
+finalize()
Bak erySys tem DB
-name : String
+List of operations() Bake rySys te m
-paymentMode
Figure 2.9: Class Diagram for the Bakery System
2.2.2.4 Sequence Diagram
Sequence diagram is an interaction diagram that shows how processes operate with one another and in what order. Sequence diagrams can also be used to model the behavior of use cases. Figure2.10 refers to the use case Place Order, where the lifeline represents the actor and classes. The actor Online Customer interacts with the class BakerySystem and cthe lassBakerySystem interacts with the BakerySystemDB. Messages are represented by the arrows and every message is numbered. Online Customer selects the bakery item or items from the list of bakery products by invoking the getOrder() method for the selected bakery items. The classBakerySystem needs the actor to choose the payment method and online Customer invokes the methodgetPayment(), when the payment is made, the total amount is verified by the BakerySystem. To process the order BakerySystemDB class invokingexecuteQuery method for further action.
2.2. UML MODEL FOR A BAKERY SYSTEM 17
: Online Customer : BakerySystem : BakerySystemDB
2: getOrder() 3: select payment method
4: getPayment() 5: verify payment details
6: executeQuery(sql=) 1: select bakery items
Figure 2.10: Sequence Diagram for Place Order
2.2.3 Relationship of the UML Diagrams
This section presents the relationship between the diagrams discussed in Section 2.2.2.
The analysis model of the bakery system provides a conceptual model, that focuses on the domain concepts, existing use cases and actors. The analysis model also describes the concepts (i.e., things, objects), association between concepts and attributes of the concepts. For analysis model following dia-grams are used: use case diagram, activity diagram, sequence diagram and class diagram. The activity and sequence diagrams are used to model the use cases, while the class diagram presents the associated classes and their relationship.
The design model of the bakery system presents the blueprint for the developers to implement the software product. The goal of the design model is to provide a sufficient level of detail. The design model involves representation of both classes and objects depending upon the diagram. The connection between classes and their objects signify the basic relationships between classes as well as messaging between objects. The design model for the bakery system consists of class diagrams, sequence diagrams, activity diagrams and state machine diagrams as shown in Figure 2.11.
Implementation model is considered to be a set of diagrams from the design model to generate code manually or automatically. Not all diagrams are considered for
the code generation. Figure 2.11 shows the class and state machine diagrams to generate executable code. The implementation model is considered to be an executable model in Chapter4. However, we developed only analysis and design models for the bakery system example described in Chapter6.
Use Case Diagram
Activity Diagram Class Diagram Sequence Diagram
Class Diagram Sequence Diagram Activity Diagram
State Machine Diagram Analysis Model
Design Model
Implementation Model
Class Diagram State Machine Diagram
Figure 2.11: Flow of the Developed Model