|
|
|
|
|
|
|
|
|
|
- Overview
- Types of 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 make up a system. To view the system from different perspectives, the Unified Modeling Language (UML) defines nine different diagrams. Each diagram represents a system state. WINDEV, WEBDEV and WINDEV Mobile allow you to create the following nine types of UML models: This chapter only provides an overview of UML. For more information about UML, see the specific documentation. Class diagram A class diagram describes the structure of a system via classes and the relationships among them. Class diagrams are the most common diagrams in object-oriented systems modeling. 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:
- the name of the class indicates what the class is, not what it does.
- the attributes of the class determine the class characteristics.
- the class operations represent the actions the class can execute.
For example, the Inventory class contains the ProductList attribute. This class also groups the AddProduct and DeleteProduct operations. These operations can be applied to the class instances.
Remark: UML provides three visibility levels for attributes and operations:- Public: the element is visible to all other classes.
- Protected: the element is visible to the class and its subclasses.
- Private: the element is visible to the class only.
- Relationship: describes how classes interact with each other. There are three types of relationships:
- 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 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 Inventory class: before adding a product to an order, you must make sure the 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 and Speed_Boat classes are derived from the Boat class.
- Package: used to divide and organize the diagram representation (in the same way that directories organize files). Each package can contain classes and relationships.
The generation of a class diagram allows you to create the structure of the WINDEV, WEBDEV and WINDEV Mobile 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 the users that interact with the application. For example, a person who works in a bank as a loan manager. If this person has an account the same bank, he or she will also play the role of customer.
- Use case: describes a sequence of actions performed 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 an actor with a use case. There are three types of relationships:
- Association: Structural relationship between two linked elements.
- Dependency: Indicates that one element uses or depends on another element. For example, a bank customer may get cash from an ATM. In this case, the Get Cash action depends on the Customer.
To withdraw money, the Customer must enter a PIN number. In this case, the Get Cash action depends on the Password. - Generalization: Relationship in which elements are organized based on a hierarchy.
For example:- the Customer actor can be of two types: Individual customer or Company customer.
- the identity can be checked via two methods: a password or a fingerprint.
- Package: divides and organizes the diagram representation (in the same way that directories organize files). Each package can contain actors and use cases.
Object diagram An object diagram represents a set of objects and how they relate to each other at a certain moment in 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 can create an object from a class in this diagram (Drag and drop it from the "UML analysis" pane). - composite object: visually represents an object made of other objects. For example: a window that contains scrollbars, buttons, etc.
- link: represents the relationship between different objects.
Component diagram A component diagram describes the physical and static architecture of a software application. For example: source files, libraries, executables, etc. For example, the diagram below presents the operating mode of a program allowing you to log in in text mode in Unix. A component diagram includes the following elements: - module: represents the different physical elements that make up a software application. For example: a file, a library, etc, ...
A module can be represented:- by a specification that shows the module interface. This specification can be generic for classes that can be configured.
- by its body that presents the module implementation.
- task: represents a component that has its own control flow (thread).
- main programs of the software application.
- subprograms: groups the procedures and functions that do not belong to any class.
Activity diagram 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: represents a specific step in a workflow. For example: "Print an estimate", "Open the window", etc.
- synchronization bar: synchronizes 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 happen in parallel.
- object: relates activities to the object that performs them. For example, the "Order" and "Pay" activities are related to the "Customer" object; the "Teach" and "Check knowledge" activities are related to the "Teacher" object.
- send signal: represents a signal sent to an object.
- accept event: represents the acceptance of an event coming from an object.
- transition: represents the transition from one completed activity to another. For example: "Too much water", "Enough money", etc.
Sequence diagram 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", etc.
- activation period of an object: activation periods can be inserted into the object lifeline. 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 sender 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: "Picks up", "Ring", etc.
Collaboration diagram A collaboration diagram presents the structural organization of objects that send and receive messages. For example, the diagram below represents a person that uses an elevator: A collaboration diagram includes the following elements: - object: represents the different objects used.
- actor: represents an element external to the system. A person, for example.
- message: represents the messages exchanged between different objects.
State-transition diagram A state-transition diagram presents a sequence of states that an object goes through during its lifecycle. It describes how the states of an object or component change. A state is defined by its duration and stability. A transition represents the change from one state to another. 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 the object attributes at a given time.
- initial state: represents the state when the system is started.
- final state: represents the state of the system at the end of the operation.
- superstate: used to structure the diagram by specifying several distinction levels between the states.
- history: represents the last active state of a superstate (or composite state).
- entry/exit points: represent the states in a superstate. This allows you to link these states to other states that do not belong to the superstate.
- transition: represents the change from one state to another.
Deployment diagram A deployment diagram shows the physical arrangement of devices (hardware/nodes) in a system as well as the relationships between the executables and these devices. For example, the diagram below represents the hardware used in a company: A deployment diagram includes the following elements: - node class: represents a class of a physical resource. For example: server, PC, printer, etc.
- node instance: represents a physical resource. For example: server 3, printer 70, etc.
- connection: depicts the communication path between two nodes. For example: ISDN or TCP/IP link.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|