ONLINE HELP
 WINDEVWEBDEV AND WINDEV MOBILE

Help / WEBDEV concepts / Part 4 - Advanced concepts
  • 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
WINDEV
WindowsLinuxUniversal Windows 10 AppJavaReports and QueriesUser code (UMC)
WEBDEV
WindowsLinuxPHPWEBDEV - Browser code
WINDEV Mobile
AndroidAndroid Widget iPhone/iPadIOS WidgetApple WatchMac CatalystUniversal Windows 10 App
Others
Stored procedures
3. UML models in practice
Previous pageTable of contentsNext page
Overview
The main objective of a development team is to create optimized applications, capable of satisfying the ever-changing needs of their users.
Modeling an application defines 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 build 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:
  • Class diagram,
  • Use case diagram,
  • Object diagram,
  • Component diagram,
  • Activity diagram,
  • Sequence diagram,
  • Collaboration diagram,
  • State-transition diagram,
  • Deployment diagram.
This chapter only provides an overview of UML. For more information about UML, see the specific documentation.
Types of UML diagrams

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, a diagram can represent a stock management system.
A class diagram includes the following elements:
  • Class: represents the application structures. Each class is divided into four 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 operations of the class represent the possible actions on the class.
    • the properties of the class. A property is a specific type of attribute whose value can be read or written using the getter and setter functions, respectively. Using a function allows you to perform complex operations when reading or writing a characteristic. For example, a class used to model an order form could have a "TotalValue" property accessible in read-only mode. In this case, the getter does not exist and the setter iterates over the list of elements of the order and calculates the value when the function is called, rather than storing the value in an attribute.
    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 class and Speed Boat class are derived from the Boat class.
  • Packages: divides and organizes 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 they have an account in the same bank, they 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, etc, ...
    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. Three types of relationships are available:
    • 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 Input.
    • Generalization: Relationship in which elements are organized based on a hierarchy.
      For example:
      - there are two types of Customer actor: Individual Customer or Enterprise Customer.
      - there are two ways to verify the user's identity: 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.
  • UML package: divides and organizes the diagram representation (in the same way that directories organize files). Each package can contain objects and composite objects.

Component diagram

A component diagram shows the physical and static architecture of a system software. For example: source files, libraries, executables, etc.
For example, the diagram below presents the steps of a program that allows users to log in in text mode in Unix. The "login" program uses the data from the "etc/passwd" file and a library:
A component diagram includes the following elements:
  • module: represents the different physical elements that build a software system. 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 configurable classes.
    • by its body that presents the module implementation.
  • task: represents a component that has its own control flow (thread).
  • main program of the software system.
  • subprogram: groups procedures and functions that do not belong to any classes.
  • package: divides and organizes the diagram representation (in the same way that directories organize files).

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: "Create a quote", "Open a window", "Evaluate", 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 "Evaluate" 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: shows the passage from a terminated activity to another activity. For example: "Too much water", "Enough money", etc.
  • package: divides and organizes the diagram representation (in the same way that directories organize files).
  • initial state: represents the status of the process before the activity starts. Several different initial states can be found.
  • final state: represents the state of the process at the end of the activity. Several different final states can be found.

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.
  • object activation period: You can insert activation periods into the lifeline of an object. These periods indicate 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.
  • package: divides and organizes the diagram representation (in the same way that directories organize files).

Collaboration diagram

A collaboration diagram presents the structural organization of objects that send and receive messages.
For example, the diagram below presents the process of a person using 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.
  • package: divides and organizes the diagram representation (in the same way that directories organize files).

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 for 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.
  • package: divides and organizes the diagram representation (in the same way that directories organize files).

Deployment diagram

A deployment diagram shows the physical layout of the hardware components (nodes) used in a system as well as the association between the executable programs and these components.
For example, the diagram below shows the different hardware components 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.
  • connexion: represents communication between two nodes. For example: ISDN or TCP/IP link.
  • package: divides and organizes the diagram representation (in the same way that directories organize files).
Previous pageTable of contentsNext page
Comments
Click [Add] to post a comment

Last update: 05/24/2023

Send a report | Local help