Behavioral models are models of the dynamic behavior of the system as it is executing. They show what happens or what is supposed to happen when a system responds to a stimulus from its environment. You can think of these stimuli as being of two types:
Data. Some data arrives that has to be processed by the system.
Events. Some event happens that triggers system processing. Events may have associated data but this is not always the case.
Many business systems are data processing systems that are primarily driven by data. They are controlled by the data input to the system with relatively little external event processing. Their processing involves a sequence of actions on that data and the generation of an output. For example, our bookstore system will accept information about orders made by a customer, calculate the costs of these orders, and using another system, it will generate an invoice to be sent to that customer.
Data-driven models show the sequence of actions involved in processing input data and generating the associated output. This is very useful during the analysis stage since they show end-to-end processing in a system which means that they show the entire action sequence of how input data become output data. In ither words, it shows the response of the system to particular input.
In UML, activity and sequence diagrams can be used to describe such data flows. Note that these are the same diagram types we used for interaction modeling but now the emphasis is put on the processing itself, not on the objects that will participate in processing (interactions). That is why acivity diagrams are better used for that purpose since the lifelines of sequence diagrams depict objects and actors therefore some attention must be paid to responsibility allocation when using sequence diagrams.
The basic processes of the online store (starting from the insertion of a new product through browsing and selecting products to buy till tracking the order's delivery and provide feedback) is shown on the following activity diagram.
The first action in the system is populating it with some products. This is the administrator’s job. The next step in the flow is a fork indicating that the following activities can be executed parallelly. The manager can set discounts for customers and products in an arbitrary order. The next step joins the two branches of the flow. Based on the information set up, the administrator can compose and send newsletters. The customer receives the newsletter sent and visits the site. He/she performs a browsing or searching action. Then, he/she selects one or more products from the list that can be placed either onto the bookshelf or into the shopping cart. If items got onto the shelf and the customer wants to place an order later, the first step is to move selected items into the shopping cart. In the other case, when items got into the shopping cart and the customer wants to save them for later, the first step is to move the selected items onto the shelf. Then, the customer can continue with browsing/searching or can place an order. If the items got earlier onto the bookshelf or into the shopping cart and the customer does not want to either place an order or save items, he/she can continue with browsing/searching products. Steps described previously can be repeated as many times as needed.
If the customer finishes with browsing/searching/selecting and would like to place an order, items of the shopping cart are used to create the new order. The system calculates the total price for the order. At this point, the customer can cancel the order process. If he/she continues with ordering, some pieces of order data (e.g. shipping and billing address) should be filled and the payment mode must be selected. Then if the customer does not cancel the process, the system validates the entered information and as a result, the order is actually created. Customers can check the status of their latest order (pending order) later. The status can be updated by the administrator. Then, customers can send a feedback that is processed also by the administrator. Thereafter, the manager can generate reports about sales data in order to support decision making.
Event-driven modeling shows how a system responds to external and internal events (stimuli). It is based on the assumption that a system has a finite number of states and that an event (stimulus) may cause a transition from one state to another.
The UML supports event-based modeling using state machine diagrams
The following state machine diagram shows the internal states and transitions of a shopping cart.
When the shopping cart is initiated, it will be in an Empty state. Whenever products are added, a transition to Collecting state is performed. When the shopping cart is in the Collecting state and a Product deleted stimulus happens then based on the guards (if the number of products in cart is equal to 1 or greater) a transition to Empty state might happen.
One might argue that Empty and Collecting are very similar that it does not worth separating them. This can be a valid point, however, the reason why we separated is that when converting a bookshelf's contents (like a wishlist) to shopping cart contents will not allow having an empty cart so the inclusion of the entry point resulted in the separation.
When the cart is in the Empty state, it cannot receive a Product deleted stimuli (there is no such transition starting from Empty) therefore this model disallows deleting products from an empty cart (of course, it is impossible). This is a second reason why states Empty and Collecting has been separated.
The state “Show summary” contains an effect that is executed upon entering the state: total price should be counted as it should be presented to the customer.
The UML notation lets you indicate the activity that takes place in a state. In a detailed system specification you have to provide more detail about both the stimuli and the system states. These are shown in the following tables with a tabular description of each state and how the stimuli that force state transitions are generated.
Table 3.4. States of a shopping cart
|Empty||The shopping cart does not contain any products.|
|Collecting||The cart contains some products.|
|Show summary||Overview of the shopping cart contents are shown.|
|Checkout||Cart contents are ordered.|
Table 3.5. Stimuli of a shopping cart
|Product added||The user pressed thebutton.|
|Product deleted||The user selected a product and pressed thebutton.|
|Finish||The user pressed thebutton.|
|Cancel||The user pressed thebutton.|
|Accept||The user pressed thebutton so the contents of the cart are ordered.|
|Abandon order||The user pressed thebutton.|
A less detailed state machine diagram showing a possible set of order statuses is shown below:
An order is in NEW state when being created. It changes state when its items are obtained from the inventory and the assembled package is ready for dispatching. Its state becomes to DISPATCHED when the package is under delivering. When the customer receives the package, the state of the order will be DELIVERED. After processing the customer’s feedback, the state can be CLOSED.