What you need to know about UML diagrams – Behaviour diagrams (2)


We continue our serie of blog posts about the most used UML diagrams. The Unified Modeling Language™ (UML‧Ⓡ) is a way of describing software architecture using a range of diagrams. UML have been created to put different profiles around the table, and speak the same language : business analysts, software architects and developers. This modeling language, as a standard language, can be applied to any sectors (banking, internet, aerospace, finance etc.), be used with major software development methods and for several implementation platforms. We can identify two main types of diagrams :

  • structure diagrams to show the static structure of a system including abstraction, real word, implementation, and how they are related to each other.
  • behaviour diagrams to show the dynamic behaviour of the objects in a system, a serie of changes to the system over time.

The last blog dealt with 2 structure diagrams: the class diagram and the object diagram. Today, we are going to talk about behaviour diagrams illustrated by an example describing an IKEA procurement system, an easy system known to everyone to clearly understand each diagram type.

The use case diagram: describe at high level the main behavior of each actor

This diagram shows the different use cases or actions that actors can take. What ‘actors’ means? The objects with their own behaviour. In the example, we have 3 of them:

  • The “Customer”
  • The “StoreService”
  • The “StockService”

As you can see, an actor represents an object from the system, and even if it is represented by a “stickman”, it can represent the equivalent of a non-person object (like “StoreService” or “StockService”). You can find the involved objects and classes in the previous article about Structural diagrams.

usecase diagram

Through the different use cases presented in the diagram, we see 3 major actions that the customer can carry out: examine a product, retrieve information about it or buy it. We can notice that some actions include other actions and actors. For example, the request for information about a product also leads to the request for availability of a product and its price. These behaviors are expressed at a high level of details to focus on the main actions of each actor.

The activity diagram: describe the functionality of the business system

The activity diagram shows the different possible execution paths for the customer in a “Buy Items” context. First, the user examines the presentation product. Then, he has to make a choice, modeled by the diamond. Depending on a state, the diamond indicates the path taken rather than another. So, if the customer is not interested, the flow goes to the breakpoint. Instead, if he is interested by the product, the next step is the availability check phase. If the product is available, the user asks for the price. He could eventually jeopardize his purchase because of the price but in this case, we face a compulsive buyer. If he can buy, he does.

activity diagram

The sequence diagram: focus on the message interchange between lifelines

This diagram represents for a very precise scenario: the method calls made, the instances created and the returns that exist when the objects “communicate” with each other by method calls. It is mainly used for describing the internal mechanic of a behavior. The following example shows a more refined view from the three behavior “Examine Item”, “Get Information about Item” and “Buy Item” from the use-case diagram and activity diagram.

sequence diagram

This diagram shows a successful purchase of a product by the customer “John”. Each vertical lines represents the lifeline of a product. The “Order” lifeline is lower and linked to the “CreateOrder (John)”. It means that this particular command did not exist before this specific point in the execution scenario. In this diagram, we can see the “time” of a request execution, represented by the size of the rectangles on the lifelines (dotted lines). On each of the arrows, you can see which the methods are called. These methods are those shown in the diagram class. The dotted arrows returning after a call show the return values generated by method calls. If you follow the different links, you can see exactly how a purchase is going “in-house”. The customer requests to examine the presentation product. Then, he requests its availability from the warehouse, which induces a call to stock for an availability request. In this scenario, the stock, and therefore the store location, responds “true”. From there, the customer asks to put his product in his shopping cart. If an order does not yet exist for the customer (which is the case in this scenario), an “Order” is created by the warehouse and the product is added to the order. Then the customer asks for the total price of the order, which is calculated by the store by recovering the price of the “Order” (which passes through the price of the product), and then, pays. Following payment, the customer receives his product, taken from inventory.

The state machine diagram : model discrete behaviour through finite state transitions

This diagram describes the state transitions. This type of diagram can be very complexe sometimes. The idea is to consider that an object, during its lifetime, passes from one state to another depending on a certain number of conditions. A state machine diagram must be deterministe.

Behaviour State Machine Diagram

In the example we proposed, the states represented are those of a product and, more precisely, its availability. The condition that causes the product to switch from one report to another is the state of the stocks. When asked if the presentation product is available, the system checks whether there is at least one such product in stock. If so, it is then “Available”. On transitions, we use OCL (Object Constraint Language), a constraint description language to represent the condition under which the presentation product changes state.

These diagrams are called behaviour diagrams because they show the dynamic behaviour of the objects in the system describing changes over time. The behaviour diagrams are totally complementary to structure diagrams. All these diagrams reunite give you a complete vision of your system and help you to build your app for example.

Start experiencing these models with GenMyModel:

You’d also like to read: What You Need To Know About UML Diagrams – Structure Diagrams (1)

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedIn