- The different UML diagrams
- Class diagram
- Use case diagram
- Object diagram
- Component diagram
- Activity diagram
- Sequence diagram
- Collaboration diagram
- State-transition diagram
- Deployment diagram
3. UML models in practice
The main objective of a development team is to create optimized applications, capable of satisfying the ever-changing needs of their users.
The modeling of an application is used to specify the structure and the expected behavior of a system. It helps understand its organization and detect simplification and reuse opportunities as well as manage potential risks.
A model is a simplification of reality. It allows you to better understand the system to develop.
A diagram is the graphical representation of a set of elements that constitute the system. To view the system under different perspectives, the UML language (Unified Modeling Language) proposes nine diagrams, each one representing a system state.
WINDEV allows you to create these nine types of UML model:
This chapter only provides an overview of UML. For more details, see a specific documentation about the UML language.
The different UML diagrams
A class diagram is used for modeling the structure of a system via classes and via relationships between these classes.
The class diagrams are the most common diagrams in the modeling of object-oriented systems.
For example, the following diagram presents the management of stocks:
A class diagram includes the following elements:
- Class: represents the application structures. Each class is divided into three compartments:
For example, the Stocks class contains the ListProducts attribute. This class also groups the AddProduct and RemoveProduct operations. These operations can be applied to the class instances.
- the name of the class indicates what the class is, not what it does.
- the class attributes give the class characteristics.
- the class operations represent the possible actions on the class.
Remark: The UML language defines three visibility levels for the attributes and the operations:
- Public: the element is visible to all other classes.
- Protected: the element is visible to the class itself and to its sub-classes.
- Private: the element is visible to the class only.
- Relationship: describes the behavior of classes between themselves. Three types of relationships are available:
- Association: Structural relationship between classes. For example, the Orders class is linked to the Product and Customer classes. A Customer can place several Orders. An order contains several products. An order must necessarily contain at least one product.
- Dependency: Use relationship that establishes that the instances of a class are linked to the instances of another element. For example, the Orders class uses the Stocks class: before adding a product into an order, you must make sure this product is available in stock.
- Generalization: Relationship between a general class (parent) and a specific class (child) that derives from it. For example, the Sail Boat class and Speed Boat class are derived from the Boat class.
- Package: used to divide and organize the diagram representation (how the directories organizes the files). Each package can contain classes and relationships.
Via the generation of a class diagram, you have the ability to create the structure of WINDEV classes used in your application.
Use case diagram
A use case diagram is used to view the behavior of a system in such way that:
- the user can understand how to use each element.
- the developer can implement these elements.
For example, the behavior of a cell phone can be described via a use case diagram.
A use case diagram includes the following elements:
- Actor: represents the role of application users. For example, a person who works in a bank will be the loan manager. If this person has an account in this bank, he will also play the role of Customer.
- Use case: describes a sequence of actions run by the application. For example, Place an order, Enter an invoice, Create a new Customer entry, ...
A use case describes the actions performed by an application but it does not specify how the application performs these actions.
- Relationship: describes the behavior of actors in relation to the use cases. Three types of relationships are available:
- Association: Structural relationship between two linked elements.
- Dependency: Relationship establishing that an element uses another one. For example, a bank customer may get cash from an ATM. In this case, the Get Cash action depends on the Customer.
In order to get cash, the Customer must enter his PIN number. In this case, the Get Cash action depends on the Password Input.
- Generalization: Relationship used to organize the elements according to a hierarchy.
- two types of Customer actor are available: Individual customer or Company customer.
- the identity check can be performed according to two methods: typing a password or checking a fingerprint.
- Package: divides and organizes the diagram representation (like the directories organize the files). Each package can contain actors and use cases.
An object diagram presents a set of objects and their relationships at a given time.
An object diagram is used to show a context (before or after an interaction between objects for example).
For example, the diagram below presents a section of the general structure of motorcycles:
An object diagram includes the following elements:
- object: represents a class instance.
Remark: If a class diagram is opened, you have the ability create an object from a class found in this diagram (Drag and Drop from the "UML analysis" pane).
- composite object: visually represents an object made of other objects. For example: a window that contains scrollbars, buttons, ...
- link: presents the relationships between the different objects.
A component diagram describes the physical and static architecture of a computer application. For example: source files, libraries, executables, ...
For example, the diagram below presents the operating mode of a program allowing you to log in text mode in Unix.
A component diagram includes the following elements:
- module: represents the different physical elements that constitute a computer application. For example: a file, a library, ...
A module can be represented:
- by a specification that shows the module interface. This specification can be generic for the customizable classes.
- by its body that presents the module implementation.
- task: represents a component that includes its own control flow (thread).
- main programs of the application.
- sub-programs: groups the procedures and the functions that do not belong to classes.
An activity diagram represents the behavior of a method or the flow of a use case.
For example, the following diagram presents the flow of a dam:
An activity diagram includes the following elements:
- activity: presents a specific step in a the execution of a mechanism. For example: "Print an estimate", "Open the window", ...
- synchronization bar: used to synchronize the different activities:
- by indicating the activities that must be performed before a given activity. For example: "Press clutch" and "Change gear" before "Release clutch".
- by indicating the activities that will be performed in parallel.
- object: used to attach activities to the object that performs these activities. For example, the "Order" and "Pay" activities are attached to the "Customer" object; the "Teach" and "Check knowledge" activities are attached to the "Teacher" object.
- sending signal: represents the sending of a signal toward an object.
- waiting for signal: represents the wait for a signal coming from an object.
- transition: represents the move from an activity that is ended to another one. For example: "Too much water", "Enough money", ...
A sequence diagram represents the chronological order of messages sent and received by a set of objects.
For example, the following diagram represents the beginning of a phone call:
A sequence diagram includes the following elements:
- object: represents the different objects used. Each object is represented by a square at the top of a dotted line. This line represents the object lifespan. For example: "Caller", "Callee", ...
- activation period of an object: activation periods can be inserted into the line representing the object lifespan. These periods represent the times when the object is active.
- message: represents, via horizontal arrows, the message exchanged between the different objects. These arrows are oriented from the message issuer to the recipient. The order in which the messages are sent is given by the position of the arrows on the vertical axis.
For example: "Hang up", "Ring", ...
A collaboration diagram presents the structural organization of objects that send and receive messages.
For example, the diagram below presents the use of an elevator by a person:
A collaboration diagram includes the following elements:
- object: represents the different objects used.
- actor: presents an element external to the system. A person for example.
- message: represents the messages exchanged between different objects.
A state-transition diagram presents a sequence of states that an object goes through during its lifecycle. It is used to describe the changes of states for an object or for a component.
A state is defined by its duration and by its stability.
A transition represents the instantaneous change from one state to another one.
A transition is triggered:
- by an event.
- automatically when no triggering event is specified.
For example, the diagram below presents the different steps of a car wash:
a state-transition diagram includes the following elements:
- state: represents the value of object attributes at a given time.
- initial state: represents the state when the system is started.
- final state: represents the status of system at the end of operation.
- super-state: used to structure the diagram by specifying several distinction levels between the states.
- history: represent the last active state of a super-state.
- stump: used to symbolize the states found in a super-state. This allows you to link these states to other states that do not belong to the super-state.
- transition: represents the switch from one state to another one.
A deployment diagram presents the physical layout of hardware devices (nodes) used in a system as well as the association between the executable programs and these devices.
For example, the diagram below presents the different hardware devices used in a company:
A deployment diagram includes the following elements:
- node class: represents a class of hardware resource. For example: a server, a PC, a printer, ...
- node instance: represents a hardware resource. For example: the server #3, the printer #7, ...
- connection: describes the communication support between two nodes. For example: RNIS or TCP/IP link.
Click [Add] to post a comment