We are about to begin a 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.
In this first blog post, we introduce two of the most used UML structure diagrams with examples. The next blog posts will feature behaviour diagrams and other specific ones.
The example used throughout this blog post is about an IKEA procurement system. A customer accesses a store to buy some items. These items are part of a “stock”, and the customer can buy them through an order. It is an easy system known to everyone to clearly understand each diagram type.
The class diagram: all the concepts used in the system
The class diagram shows structure of the designed system, subsystem or component. To better understand, the class diagram give the general structure of all IKEA stores in France or worldwide and represents categories (“Store”, “Customer”…).
This diagram represents the differents concepts that will be used in the system for the modelling of an IKEA procurement system. There are several object types:
- The customer modeled by the class “Customer”
- The order placed by a customer modeled by the class “Order”
- The physical storage location modeled by the class “Store”
- The stock modeled by the class “Stock”
Also, the products a customer can buy are represented by the class “Item”. They have a price and they are specialized in two subclasses: the showcase items (“ShowcaseItem”) and the stock items (“StockItem”). The methods describe actions that can be requested for the object. For example, the method “IsAvailable” on a “Store” take a “ShowcaseItem” as parameter and request if the product is in stock or not. On this diagram, you can also notice that the referral from “Stock” to “StockItem” is a composite relation. It indicates a “containment” constraint quite strong as it introduces a dependency between the two objects lifecycles (ie: if the “Stock” is destroyed, so does the contained “StockItems”). More generally, a “StockItem” is in a stock but when ordering it can be moved in an “Order”. The relation between “Order” and “StockItem” is an aggregation. It means that during an ordering, a “StockItem” is then contained in an “Order”, but its lifecycle is not bound to this “Order”. If the “Order” is destroyed, the “StockItem” is not. Thanks to this “Order”, the customer will retrieve the purchased product.
The object diagram: a possible state of the system
The object diagram or the instance level class diagram shows instance specifications of classes and interfaces (objects), slots with value specifications and links (instances of association). This type of diagram is like a scenario describing a system status at a given time. The object diagram indicates the links between the instances of the system and sets certain values.
In this diagram, the different items are uniquely identified, not such as a category. For example, the object diagram precisely identify one IKEA store (ie. Vierzon city) and one or several customers (John, Marie…). We can see, in the example above, a store “s1” named “IKEA” and a customer “c1” named “John”. We can also see the relationships that unite them and relations between a specific product in the stock and during the order.
These two diagrams represent the static structure of the system, as no behaviour is modeled. They are not using time related concepts, do not show the details of dynamic behavior. Starting analyzing a system using a class and object diagrams is always a good start as it provides a great way of expressing abstract concepts. On one hand, the class diagram is one of the main building block of UML and defines the main concepts that will be part of the final system. On the other hand, the object diagrams are more concrete than the class diagram, and give the ability to represent a system state. They are often use as tests scenarios or examples. In the next blog post, we will talk about 4 other diagrams (use case, sequence, activity and state machine) that propose a system execution view (a logic execution flow or changes of state). The execution represented can be abstract (with the activity diagram for example) or be much more technical (with the sequence diagram). Stay tuned!
Start experiencing these models with GenMyModel: