Menu
Is free
registration
home  /  Installation and configuration/ General characteristics of the UML language. Unified Modeling Language Basics Uml Internal Structure Diagram

General characteristics of the UML language. Unified Modeling Language Basics Uml Internal Structure Diagram

UML diagram is a specialized graphical description language designed for object modeling in the development of various software... This language has a wide profile and is an open standard that uses various graphic symbols to create an abstract model of the system. The UML was created to provide definition, visualization, documentation, and design of all kinds of software systems... It is worth noting that the UML diagram itself is not a programming language, but it does provide for the possibility of generating a separate code based on it.

Why is it needed?

The UML doesn't end with modeling all kinds of software. Also, this language is actively used today for modeling various business processes, conducting systems engineering, as well as displaying organizational structures.

Using the UML, software developers can enforce a complete convention in the graphical notations used to represent general concepts such as component, generalization, class, behavior, and aggregation. This achieves a greater degree of concentration on architecture and design.

It is also worth noting that there are several types of such diagrams.

Class diagram

A UML class diagram is a static structure diagram designed to describe the structure of a system, as well as show attributes, methods, and dependencies between several different classes.

It is worth noting the fact that there are several points of view on the construction of such diagrams, depending on how they will be used:

  • Conceptual. In this case, the UML class diagram describes the model of a specific domain, and only classes of applied objects are provided in it.
  • Specific. The diagram is used in the design process of various information systems.
  • Implementation. The class diagram includes all kinds of classes that are directly used in the program code.

Component diagram

A UML Component Diagram is a fully static structural diagram. It is intended to demonstrate the division of a certain software system into various structural components, as well as the connections between them. A UML component diagram as such can use all sorts of models, libraries, files, packages, executable files, and many other elements.

Composite / Composite Structure Diagram

The UML Composite / Composite Structure Diagram is also a static structure diagram, but it is used to show the internal structure of classes. If possible, this diagram can also demonstrate the interaction of elements found in the internal structure of the class.

A subtype of them is the UML-diagram of cooperation, which is used to demonstrate the roles, as well as the interaction of various classes within the boundaries of cooperation. They are quite handy when you need to model design patterns.

It is worth noting that UML class diagram types and composite structure types can be used at the same time.

Deployment diagram

This diagram is used in order to simulate working nodes, as well as all kinds of artifacts that were deployed to them. UML 2 deploys artifacts to various nodes, while the first version deploys exclusively components. Thus, the UML deployment diagram is used primarily by the second version.

A manifest dependency is formed between the artifact and the component that it implements.

Object diagram

This view allows you to see a full or partial snapshot of the system being created at a certain point in time. It completely displays all instances of classes of a particular system, indicating the current values ​​of their parameters, as well as the links between them.

Package diagram

This diagram is structural in nature, and its main content is all kinds of packages, as well as the relationship between them. In this case, there is no hard division between several structural diagrams, as a result of which their use is most often found solely for convenience, and does not carry any semantic meaning. It is worth noting that different elements can provide other UML diagrams (examples: packages and the package diagrams themselves).

Their use is carried out in order to ensure the organization of several elements into groups according to a certain criterion, in order to simplify the structure, and also to organize work with the model of this system.

Activity diagram

UML Activity Diagram displays the decomposition of a specific activity into several component parts... In this case, the concept of "activity" refers to the specification of a certain executable behavior in the form of parallel, as well as coordinated sequential execution of various subordinate elements - nested types of activities and various actions, united by threads coming from the outputs of a certain node to the inputs of another.

UML activity diagrams are often used to model various business processes, parallel and sequential computations. Among other things, they simulate all kinds of technological procedures.

Automaton diagram

This view is also called a UML state diagram. Has a presented state machine with simple and composite states and transitions.

A state machine is a specification of a sequence of different states through which a certain object passes, or interaction in response to some events in its life, as well as the object's responses to such events. A state machine that uses a UML statechart is attached to the source element and used to define the behavior of its instances.

The so-called dragon-schemes can be used as analogs of such diagrams.

Use case diagrams

The UML use case diagram depicts all the relationships that arise between actors, as well as the various use cases. Its main task is to provide itself as a full-fledged means by which a customer, an end user, or some developer can jointly discuss the behavior and functionality of a particular system.

If a UML use case diagram is used in the process of modeling a system, then the analyst is going to:

  • Clearly separate the simulated system from its environment.
  • Identify the actors, ways of their interaction with this system, as well as its expected functionality.
  • Set in the glossary as a subject area various concepts that relate to a detailed description of the functionality of this system.

If a usage diagram is developed in UML, the procedure begins with a textual description, which is obtained when working with a customer. At the same time, it is worth noting the fact that various non-functional requirements in the process of drawing up a model of use cases are completely omitted, and a separate document will already be formed for them.

Communications

A communication diagram, just like a UML sequence diagram, is transitive, that is, it expresses interaction in itself, but at the same time demonstrates it different ways, and, if necessary, with the desired degree of accuracy, you can convert one to another.

The communication diagram depicts the interactions that occur between the various elements of the composite structure, as well as the roles of the cooperation. The main difference from a sequence diagram is that it clearly indicates the relationship between several elements, and time is not used as a separate dimension.

This type is distinguished by a completely free format for ordering several objects and links in the same way as it is done in an object diagram. If there is a need to maintain the order of messages in this free format, they are chronologically numbered. Reading this diagram starts with the original message 1.0, and then continues in the direction that messages are passed from one object to another.

Most of these diagrams show exactly the same information that a sequence diagram provides us, however, because it uses a different way of presenting information, certain things in one diagram become much easier to identify than in another. It is also worth noting that the communication diagram more clearly shows which elements each one interacts with. separate element, while the sequence diagram shows more clearly in what order the interactions take place.

Sequence diagram

A UML sequence diagram demonstrates the interactions between multiple objects, which are ordered according to their time of occurrence. This diagram displays the time-ordered interactions between multiple objects. In particular, it displays all objects that take part in the interaction, as well as the complete sequence of messages exchanged by them.

The main elements in this case are the designations of various objects, as well as vertical lines showing the passage of time and rectangles that provide the activity of a particular object or the performance of any function by it.

Collaboration diagram

This type of diagrams allows you to demonstrate interactions between several objects, abstracting from the sequence of broadcasting messages. This type of diagrams in a compact form displays absolutely all transmitted and received messages of a certain object, as well as the formats of these messages.

Due to the fact that sequence diagrams and communication diagrams are simply different views of the same procedures, Rational Rose provides the ability to create a communication diagram from a sequence diagram or vice versa, as well as fully automatically synchronizes them.

Interaction overview charts

These are UML diagrams, which are a subset of activity diagrams that include both Sequence elements and control flow constructs.

It is worth noting the fact that this format combines Collaboration and Sequence diagrams, which provide an opportunity from different points of view to consider the interaction between several objects in the system being formed.

Synchronization diagram

It is an alternate sequence diagram that clearly shows the change in state on a lifeline with a specific time scale. Can be quite useful in various real-time applications.

What are the benefits?

It is worth noting several advantages that distinguish the UML use diagram and others:

  • The language is object-oriented, as a result of which the technologies for describing the results of the analysis and design carried out are semantically close to programming methods in all kinds of object-oriented languages ​​of the modern type.
  • Using this language, the system can be described from almost any possible point of view, and in the same way, various aspects of its behavior are described.
  • All diagrams are relatively easy to read, even after a relatively quick familiarity with its syntax.
  • UML allows you to expand, as well as introduce your own graphical and textual stereotypes, which contributes to its use not only in software engineering.
  • The language has become quite widespread, and is also developing quite actively.

disadvantages

Despite the fact that building UML diagrams has a lot of its advantages, quite often they are criticized for the following shortcomings:

  • Redundancy. In the vast majority of cases, critics say that the UML is too large and complex, and often this is unjustified. It includes a lot of redundant or practically useless constructions and diagrams, and most often such criticism goes to the second version, and not the first, because in newer revisions there are more compromises "developed by the committee".
  • Various semantic inaccuracies. Because the UML is defined by a combination of itself, English, and OCL, it lacks the stiffness that is inherent in languages ​​precisely defined by the technique of formal description. In certain situations, the abstract syntax of OCL, UML and English start to contradict each other, while in other cases they are incomplete. Inaccurate description of the language itself affects both users and tool providers alike, which ultimately leads to incompatibility of tools due to the unique way of interpreting different specifications.
  • Problems in the process of implementation and study. All of the above problems create certain difficulties in the process of introducing and learning the UML, and this is especially true when the leadership forces engineers to use it forcibly, while they do not have prior skills.
  • The code mirrors the code. Another opinion is that it is not beautiful and attractive models that are important, but the working systems themselves, that is, the code is the project. In line with this view, there is a need to develop a more efficient way to write software. The UML is appreciated for approaches that compile models to regenerate executable or source code. But in reality, this may not be enough, because the language lacks Turing completeness properties, and each generated code will ultimately be limited by what a UML interpreter tool can assume or define.
  • Load mismatch. This term comes from the theory of systems analysis to determine the inability of the input of a certain system to perceive the output of another. As in any standard systems notation, UML can represent some systems in a more efficient and concise way than others. Thus, the developer is more inclined towards those solutions that are more comfortable for weaving all the strengths of the UML, as well as other programming languages. This problem is more obvious in the event that the development language does not comply with the basic principles of object-oriented orthodox doctrine, that is, it does not try to work in accordance with the principles of OOP.
  • Tries to be versatile. UML is a general-purpose modeling language that seeks to be compatible with any processing language available today. In the context of a specific project, in order for the design team to be able to achieve the ultimate goal, it is necessary to select the applicable capabilities of that language. In addition, possible ways of limiting the scope of the UML in a particular area go through a formalism that is not fully formulated, but which itself is an object of criticism.

Thus, the use of this language is not relevant in all situations.

UML or Unified Modeling Language is a graphical description language for object modeling in software development. But the use of UML is not limited to IT, another large area of ​​practical application of UML is business process modeling, systems engineering and mapping of organizational structures. The UML enables software developers to reach agreement on graphical notation to represent general concepts and concentrate on design and development.

UML advantages

  • The UML uses graphical symbols for the elements of the system being modeled, and the UML diagrams are simple enough to understand;
  • The UML makes it possible to describe systems from almost every conceivable point of view, taking into account different aspects;
  • UML is object-oriented: its methods of analysis and construction are semantically close to the programming methods used in modern OOP languages;
  • UML is an open standard. The standard develops and evolves from version to version, meeting the most modern requirements for the description of systems;
  • contains an extension mechanism that allows the introduction of additional text and graphic types, which makes it possible to use the UML not only in the IT field.

Types of UML Diagrams

There are 14 types of diagrams in UML. They can be divided into 2 categories:

  • structural representing information structure;
  • behavioral representing the behavior of the system and various aspects of interactions. A separate subspecies of behavior diagrams are considered interaction diagrams.

UML diagram type hierarchy, represented by class diagram

Structural diagrams

  1. Class diagram is a key element in object-oriented modeling. With the help of this diagram (in fact, through classes, their attributes, methods and dependencies between classes) describes the domain model and the structure of the modeled system.
  2. Component diagram displays the breakdown of the program code into large blocks (structural components) and shows dependencies between them. Components can be packages, modules, libraries, files, etc.
  3. Object diagram shows a complete or partial slice of the modeled system at a given moment in time. It represents class instances (objects), their state (current attribute values) and relationships between them.
  4. Composite structure diagram demonstrates the internal structure of classes and, if possible, the interactions between the elements of this structure.
  5. Package diagram shows packages and relationships between them. This type of diagrams serves to simplify the structure of the model (and, accordingly, to work with it) by combining the elements of the model into groups according to certain criteria.
  6. Deployment diagram simulates the deployment of software components ( artifacts) on computing resources / hardware components ( nodes).
  7. Profile diagram describes an extension mechanism that allows the UML to be tailored to a variety of domains and industries.

Example UML Class Diagram

Behavior diagrams

  1. Activity diagram shows actions ( actions) of which some activity ( activity). Activity diagrams are used to model business processes, workflows, sequential and parallel computing.
  2. Use case diagram(or use case diagram) describes the relationship between the actors (characters) and the use cases of the modeled system (its capabilities). The main purpose of a diagram is to be a one-stop-shop for customers, developers, and end users to collaboratively discuss a system — its capabilities and behavior.
  3. State diagram depicts the dynamic behavior of an entity, showing how this entity, depending on its current state, reacts to various events. This is essentially a state diagram from the theory of atoms.
  4. Communication diagram(in earlier versions cooperation diagram) shows the interactions between the parts of the composite structure and the roles of the collaboration. The diagram clearly indicates the relationship between elements (objects).
  5. Sequence diagram used to visualize a sequence of object interactions. Shows the life cycle of a given object and the interaction of actors (actors) within a use case, the sequence of messages they exchange.
  6. Interaction overview chart includes a portion of the sequence diagram and control flow constructs. Helps to consider the interaction of objects from different points of view.
  7. Synchronization diagram- a separate subtype of interaction diagrams, specializing in timing. Diagrams of this kind are used to study the behavior of objects over a certain period of time.

The UML is now the standard notation for visual modeling of software systems, adopted by the Object Managing Group (OMG) in the fall of 1997, and is supported by many object-oriented CASE products.

The UML standard offers the following set of diagrams for modeling:

· Use case diagram - for modeling the business processes of an organization or enterprise and determining the requirements for the information system being created;

· Class diagram (class diagram) - for modeling the static structure of the classes of the system and the connections between them;

Behavior diagrams

· Interaction diagrams;

· Sequence diagrams - to simulate the process of exchanging messages between objects within a single use case;

· Collaboration diagram - for modeling the process of messaging between objects within one use case;

· Statechart diagram - for modeling the behavior of system objects during the transition from one state to another;

· Activity diagram - for modeling the behavior of the system in the framework of various use cases, or modeling activities;

Implementation diagrams:

Component diagrams - to model the hierarchy of components (subsystems) of an information system;

· Deployment diagram - to model the physical architecture of the designed information system.

In fig. 1.1 presents an integrated model of the information system, including the basic diagrams that should be developed in this course project.

Rice. 1. An integrated model of an information system in the notation of the UML language

4.2. Use case diagram

A use case is a sequence of actions performed by the system in response to an event triggered by some external object (actor). A use case describes a typical interaction between a user and a system. In the simplest case, the use case is determined by discussing with the user the functions that he would like to implement in a given information system. In the UML, a use case is depicted as follows:

Fig. 2. Use case

Actor is the role that the user plays in relation to the system. Actors represent roles, not specific people or job titles. Although depicted as stylized human figures in use-case diagrams, the actor can also be external. information system that needs some information from this system. Show actors in your diagram only when they really need some use cases. In the UML, actors are represented as shapes:



Fig. 3. Actor (actor)

There are three main types of actors:

· Users;

· Systems;

· Other systems interacting with this;

Time becomes an actor if the launch of any events in the system depends on it.

4.2.1. Relationships Between Use Cases and Actors

In UML, use-case diagrams support several types of relationships between diagram elements:

Communication,

Inclusion (include),

Extension (extend),

Generalization.

Communication link Is the relationship between the use case and the actor. In the UML, communication links are shown using a one-way association (solid line).

Fig. 4. Communication link example

Inclusion link applies in situations where there is a piece of system behavior that is repeated in more than one use case. These links are usually used to model a reusable function.

Extension link is used to describe changes in the normal behavior of a system. It allows one use case to use functionality another use case.

Fig. 5. Example of connection of inclusion and extension

Generalization link indicates that several actors or classes have common properties.

Fig. 6. Generalization link example

4.3.



Interaction diagrams describe the behavior of interacting groups of objects. Typically, an interaction diagram covers the behavior of objects within only one use case. Such a diagram displays a number of objects and the messages that they exchange with each other.

Message Is the means by which the sender object requests the recipient object to perform one of its operations.

Informative message Is a message that supplies the recipient object with some information to update its state.

Request message (interrogative) Is a message requesting the issuance of some information about the recipient object.

Imperative message Is a message that asks the recipient to take some action.

There are two types of interaction diagrams: sequence diagrams and collaboration diagrams.

4.3.1. Sequence diagrams

Sequence diagram reflects the flow of events that occur within a single use case.

All of the actors (actors, classes, or objects) involved in a given scenario (use case) are shown at the top of the diagram. Arrows correspond to messages passed between an actor and an object, or between objects to perform required functions.

In a sequence diagram, an object is drawn as a rectangle with a vertical dashed line drawn downward. This line is called the lifeline of an object ... It is a fragment of the life cycle of an object in the process of interaction.

Each message is represented as an arrow between the life lines of two objects. Messages appear in the order they appear on the page from top to bottom. Each message is tagged with at least the message name. Optionally, you can add arguments and some control information as well. You can show self-delegation - a message that an object sends to itself, with the message arrow pointing to the same lifeline.

Rice. 7. Example of a sequence diagram

4.3.2. Collaboration diagram

Cooperation diagrams display the flow of events within a specific scenario (use case). Messages are ordered by time, although collaboration diagrams focus more on relationships between objects. A collaboration diagram represents all the information that a sequence diagram contains, but a collaboration diagram describes the flow of events differently. It makes it easier to understand the connections that exist between objects.

In the cooperation diagram, as in the sequence diagram, arrows indicate messages exchanged within the framework this option use. Their temporal sequence is indicated by the numbering of messages.

Rice. 8. Example of a cooperation diagram

4.4. Class diagram

4.4.1. General information

Class diagram defines the types of classes of the system and various kinds of static links that exist between them. Class diagrams also depict class attributes, class operations, and constraints that apply to relationships between classes.

A UML class diagram is a graph, the nodes of which are elements of the static structure of the project (classes, interfaces), and arcs are the relationships between nodes (associations, inheritance, dependencies).

The class diagram depicts the following elements:

· Package - a set of model elements that are logically related to each other;

· Class (class) - a description of the general properties of a group of similar objects;

· Interface is an abstract class that defines a set of operations that an object of an arbitrary class associated with this interface provides to other objects.

4.4.2. Class

Class is a group of entities (objects) that have similar properties, namely, data and behavior. An individual representative of a class is called a class object, or simply an object.

The behavior of an object in UML is understood as any rules for the interaction of an object with the outside world and with the data of the object itself.

In the diagrams, the class is depicted as a rectangle with a solid border, divided by horizontal lines into 3 sections:

The top section (name section) contains the class name and other general properties (in particular, the stereotype).

The middle section contains a list of attributes

At the bottom is a list of class operations that reflect its behavior (actions performed by the class).

Any of the sections of attributes and operations may not be displayed (as well as both at once). For a missing section, you do not need to draw a dividing line and somehow indicate the presence or absence of elements in it.

Additional sections, such as Exceptions, may be introduced at the discretion of a particular implementation.

Rice. 9. Example class diagram

4.4.2.1.Class stereotypes

Class stereotypes are a mechanism for categorizing classes.

There are three main class stereotypes defined in the UML:

Boundary

Entity

Control.

4.4.2.2.Boundary Classes

Boundary classes are classes that are located at the border of the system and the entire environment. These are displays, reports, interfaces with hardware (such as printers or scanners), and interfaces with other systems.

To find the boundary classes, you need to examine the use case diagrams. For every interaction between an actor and a use case, there must be at least one boundary class. It is this class that allows the actor to interact with the system.

4.4.2.3.Entity classes

Entity classes contain stored information. They are of the greatest importance to the user, and therefore they often use terms from the subject area in their names. Typically, for each entity class, a table is created in the database.

4.4.2.4.Control Classes

Control classes are responsible for coordinating the actions of other classes. Typically, each use case has one control class that controls the sequence of events for that use case. The controlling class is responsible for coordination, but it does not carry any functionality itself, since the other classes do not send it a lot of messages. Instead, he sends many messages himself. The manager class simply delegates responsibility to other classes, for this reason it is often referred to as the manager class.

There may be other control classes in the system that are common to multiple use cases. For example, there might be a SecurityManager class that is responsible for monitoring security events. The TransactionManager class is responsible for coordinating messages related to database transactions. There may be other managers to deal with other elements of the system's operation, such as resource sharing, distributed data processing, or error handling.

In addition to the stereotypes mentioned above, you can create your own.

4.4.2.5.Attributes

An attribute is a piece of information associated with a class. Attributes store encapsulated class data.

Since the attributes are contained within the class, they are hidden from other classes. Therefore, you may need to specify which classes are allowed to read and modify attributes. This property is called attribute visibility.

An attribute can have four possible values ​​for this parameter:

Public (general, open). This visibility value assumes that the attribute will be visible to all other classes. Any class can view or change the value of the attribute. In UML notation, the common attribute is preceded by a "+" sign.

Private (closed, secret). The corresponding attribute is not visible to any other class. A private attribute is denoted with a "-" according to UML notation.

Protected Such an attribute is available only to the class itself and its descendants. The UML notation for a protected attribute is the "#" sign.

Package or Implementation Assumes that given attribute is common, but only within its package. This type of visibility is not indicated by any special icon.

With the help of closedness or security, it is possible to avoid a situation when the value of an attribute is changed by all classes of the system. Instead, the logic for modifying an attribute will be wrapped in the same class as the attribute itself. The visibility parameters you set will affect the generated code.

4.4.2.6.Operations

Operations implement class-specific behavior. An operation has three parts - name, parameters and return type.

Parameters are the arguments received by the "input" operation. The return type refers to the result of the action of the operation.

In a class diagram, you can display both the names of the operations and the names of the operations along with their parameters and return type. To reduce the workload of the diagram, it is useful to show only the names of operations on some of them, and on others their full signature.

In the UML, operations have the following notation:

Operation Name (Argument: Data Type of Argument, Argument2: Data Type of Argument2, ...): Return Type

There are four different types of transactions to consider:

Implementation operations;

Control operations;

Access operations;

Auxiliary operations.

Implementation operations

Implementor operations implement some business functions. Such operations can be found by examining interaction diagrams. Diagrams of this type focus on business functions, and each message in the diagram can most likely be associated with an implementation operation.

Each implementation step must be easily traceable to the corresponding requirement. This is achieved at various stages of the simulation. Activity is derived from a message in an interaction diagram, messages are derived from detailed description an event flow that is generated based on the use case and the latter is generated based on requirements. The ability to trace this entire chain ensures that every requirement is implemented in code, and every piece of code implements a requirement.

Control operations

Manager operations control the creation and destruction of objects. Class constructors and destructors fall into this category.

Access operations

Attributes are usually private or protected. However, other classes sometimes need to view or change their values. There are access operations for this. This approach makes it possible to safely encapsulate attributes within a class, protecting them from other classes, but still allows controlled access to them. It is standard practice to create Get and Set operations for each class attribute.

Auxiliary operations

Helper operations are those operations of a class that it needs to fulfill its responsibilities, but which other classes should not know anything about. These are private and protected operations of the class.

To identify transactions, follow these steps:

1. Explore sequence diagrams and cooperative diagrams. Most of the messages in these diagrams are implementation activities. Reflective messages will be auxiliary operations.

2. Consider control operations. You might need to add constructors and destructors.

3. Consider access operations. For each class attribute that other classes will need to work with, you need to create Get and Set operations.

4.4.2.7.Connections

A relationship is a semantic relationship between classes. It enables a class to learn about the attributes, operations, and relationships of another class. In other words, for one class to be able to send a message to another in a sequence diagram or a cooperative diagram, there must be a relationship between the two.

There are four types of relationships that can be established between classes: associations, dependencies, aggregations, and generalizations.

Communication association

Association is the semantic link between classes. They are drawn in the class diagram as an ordinary line.

Rice. 10. Communication association

Associations can be bidirectional, as in the example, or unidirectional. In the UML, bi-directional associations are drawn as a simple line without arrows or with arrows on either side. On a unidirectional association, only one arrow is depicted showing its direction.

The direction of the association can be determined by examining sequence diagrams and cooperative diagrams. If all messages to them are sent by only one class and are received only by another class, but not vice versa, a unidirectional relationship takes place between these classes. If at least one message is sent to reverse side, the association must be bidirectional.

Associations can be reflective. Reflexive association assumes that one instance of a class interacts with other instances of the same class.

Communication addiction

Dependency relationships also reflect the relationship between classes, but they are always unidirectional and show that one class depends on the definitions made in the other. For example, class A uses methods of class B. Then when class B changes, you need to make the corresponding changes in class A.

Dependency is depicted as a dashed line between two chart elements, and the element anchored to the end of the arrow is considered to be dependent on the element anchored to the beginning of that arrow.

Rice. 11. Communication addiction

When generating code for these classes, no new attributes will be added to them. However, the language-specific statements required to support the communication will be generated.

Link aggregation

Aggregations are a tighter form of association. Aggregation is a connection between a whole and a part of it. For example, you might have a class for Car, as well as classes for Engine, Tires, and classes for other parts of the car. As a result, an object of the Car class will consist of an object of the Engine class, four objects of Tires, etc. Aggregations are visualized as a line with a diamond for a class that is a whole:

Rice. 11. Communication aggregation

In addition to simple aggregation, the UML introduces a stronger form of aggregation called composition. According to the composition, an object-part can only belong to a single whole, and, in addition, as a rule, the life cycle of parts coincides with the cycle of the whole: they live and die with it. Any removal of the whole extends to its parts.

This cascading deletion is often seen as part of the definition of aggregation, but it is always implied when the multiplicity of roles is 1..1; for example, if it is necessary to delete a Customer, then this deletion must apply to Orders (and, in turn, to Order Lines).

UML is an acronym for Unified Modeling Language. In fact, it is one of the most popular business process modeling techniques and is an international standard notation for specifying, visualizing, and documenting software development. Defined by the Object Management Group, emerged as a result of several additional UML notation systems and has now become the de facto standard for visual modeling. The fundamental principle of any object-oriented programming begins with building a model.

The UML was created out of the chaos around software development and documentation. In the 1990s, there were several different ways representations of software systems. There was a need for a more unified visual UML way of representing these systems, and as a result, it was developed in 1994-1996 by three software engineers working at Rational Software. It was later adopted as a standard in 1997 and remains so, with only a few updates.

Basically, UML is a general-purpose modeling language in the field of software development. However, it is now reflected in the documentation of several business or workflow processes, such as activity diagrams. UML type diagrams can be used as a replacement for flowcharts. They provide both a more standardized way to model workflows and a wide range of features to improve readability and efficiency.

The architecture is based on a meta-object that defines the basis for creating the UML. It is accurate enough to create an entire application. Fully executable UML can be deployed across multiple platforms using different technologies with all processes throughout the software development cycle.

UML is intended for the development of a visual modeling language by users. It supports high-level design concepts such as structures, templates, and collaboration. UML is a collection of elements such as:

  1. Programming language statements.
  2. Actors - describe the role played by the user or any other system that interacts with the object.
  3. Activities to be carried out for the execution of the work contract and presented in diagrams.
  4. A business process that includes a set of tasks that create a specific service for customers, visualized by a flowchart of sequential actions.
  5. Logical and reusable software components.

UML diagrams fall into two categories. The first type includes seven types of diagrams that represent structural information, the second includes the other seven that represent common types of behavior. These diagrams are used to document the architecture of systems and are directly involved in UML system modeling.

UML diagrams are presented as static and dynamic views of the system model. The static view includes class and compound structure diagrams that emphasize the static structure. A dynamic view represents the interaction between objects and changes in the internal states of objects using sequence, activity, and state diagrams.

A wide variety of UML modeling tools are available to simplify modeling, including IBM Rose, Rhapsody, MagicDraw, StarUML, ArgoUML, Umbrello, BOUML, PowerDesigner, and Dia.

UML is used in different ways, both in software development documentation and in business processes:

  1. Sketch. In this case, UML diagrams are used to convey various aspects and characteristics of the system. However, this is only a representation top level system and most likely will not include all the necessary details to complete the project until the very end.
  2. Forward Design - The design of the sketch is done prior to coding the application. This is to provide a better overview of the system or workflow that the user is trying to create. Many design problems or flaws can be identified, which will improve the overall health and well-being of the project.
  3. Reverse design. Once the code is written, UML diagrams appear as a form of documentation for different activities, roles, participants, and workflows.
  4. Blueprint. In this case, the diagram serves as a complete construction, which requires only the actual implementation of the system or software. This is often done using CASE (Computer Aided Software Engineering Tools) tools. The main disadvantage of using CASE tools is that they require a certain level of knowledge, user training, and management and personnel.

UML is not a stand-alone programming language like Java, C ++, or Python, however with the right tools it can become a pseudo UML. To achieve this goal, the entire system must be documented in different diagrams, and using the right software, the diagrams can be directly translated into code. This technique can only be useful if the time spent drawing the charts is less time consuming than writing the actual code. Although the UML was created for systems modeling, it has found several uses in business areas.

Following is an example UML diagram for business modeling.

One practical solution would be to visualize the process flow for telesales through an activity diagram. From the moment when the order is taken as an input, until the moment when the order is complete and a specific output is given.

There are several types of UML diagrams, and each one performs a different task, whether it is developed before implementation or after, as part of the documentation. The two broadest categories, encompassing all other types, are behavior diagram and structure diagram. As the name suggests, some UML diagrams try to analyze and depict the structure of a system or process, while others describe the behavior of a system, its participants and components.

The different types are broken down as follows:

  1. Not all of the 14 different types of UML diagrams are used on a regular basis when documenting systems and architectures.
  2. The Pareto principle also applies to the use of UML diagrams.
  3. 20% of charts are used by developers 80% of the time.

The most commonly used elements in software development are:

  • usage diagrams;
  • class diagrams;
  • sequence.

Action diagrams are the most important UML diagrams for creating business process models. In software development, they are used to describe the flow of different actions. They can be either sequential or parallel. They describe objects used, consumed or produced as a result of activities and the relationship between different activities.

All of the above is important for modeling business processes that lead from one to another, since they are interconnected with a clear beginning and end. In a business environment, this is also referred to as business process mapping. The main actors are the author, editor and publisher. Examples of UML include the following. When a reviewer reviews the draft and decides that some changes need to be made. The author then revises the draft and returns it again to analyze the overview.

Usage diagram

Cornerstone of the system - used to analyze the requirements for the level of the system. These requirements are expressed in different use cases. The three main components of a UML diagram are:

  1. Functional - presented as use cases.
  2. A verb describing an action.
  3. Actors - to interact with the system. The actor can be users, organizations, or an external application. The relationship between the participants is represented by straight arrows.

For example, for an inventory control chart. In this case, there is an owner, a supplier, a manager, an inventory specialist, and an inventory inspector. The round containers represent the actions that the actors perform. Possible actions: buying and paying for stocks, checking the quality of stocks, returning stocks or distributing them.

This type of diagram is well suited for displaying dynamic behavior between participants in a system, simplifying its presentation without reflecting implementation details.

Temporary

UML timing diagrams are used to represent object relationships when the focus is time dependent. At the same time, it is not interesting how objects interact or change each other, but the user wants to imagine how objects and subjects act along a linear time axis.

Each individual participant is represented through a life line, which is essentially a line that forms the stages, as the individual participant moves from one stage to the next. The focus is on the duration of the events and the changes that occur depending on it.

The main components of a timing chart are:

  1. Lifeline is an individual member.
  2. State Timeline - A single life path can go through various states within a process.
  3. Duration constraint - A time interval constraint that represents the duration required for the constraint to be met.
  4. Time limit - limit the time interval during which something must be done by the participant.
  5. Destruction Appearance - The appearance of a message that destroys an individual participant and depicts the end of that participant's life cycle.

Horizontal diagrams, also called state diagrams, are used to describe the various states of a component within a system. It takes a final name format because a diagram is essentially a machine that describes multiple states of an object and how it changes based on internal and external events.

A very simple machine state diagram would be in a chess game. A typical chess game consists of moves made by White and moves made by Black. White has the first move, which thus initiates the game. The end of the game can occur regardless of whether White or Black wins. The game can end in a match, resignation or a draw (different machine conditions). Statecharts are mainly used in forward and reverse UML design of various systems.

Consecutive

This type of diagram is the most important UML diagram not only among the computer science community, but also as a design layer model for developing business applications. They are popular for describing business processes due to their visually self-explanatory nature. As the name suggests, diagrams describe the sequence of messages and interactions that occur between subjects and objects. Actors or objects can only be active when needed or when another object wants to communicate with them. All communications are presented in chronological order.

For more information, see the example UML sequence diagram below.

As the example shows, structure diagrams are used to show the structure of a system. More specifically, a language is used in software development to represent the architecture of a system and how different components are interconnected.

UML class diagram is the most common type of diagram for software documentation. Since most programs currently written are still based on the object-oriented programming paradigm, using class diagrams to document software turns out to be common sense. This is because OOP is based on UML classes and the relationships between them. In a nutshell, charts contain classes, along with their attributes, also called data fields, and their behavior, called member functions.

More specifically, each class has 3 fields: name at the top, attributes right below the name, operations / behavior at the bottom. The relationship between the various classes (represented by the connecting line) constitutes a class diagram. The above example shows a basic class diagram.

Objects

When discussing UML structural diagrams, you need to delve deeper into computer science concepts. In software development, classes are considered abstract data types, while objects are instances. For example, if there is “Car”, which is a generic abstract type, then an instance of the “Car” class would be “Audi”.

UML object diagrams help software developers check whether the generated abstract structure is generating a viable structure when implemented in practice, that is, when objects are created. Some developers consider this to be a secondary level of accuracy verification. It displays instances of classes. More precisely, the generic class "Customer" now has an actual customer, for example, named "James". James is an instance of a more general class and has the same attributes, however, with given values... The same was done with the Accounts and Savings account. They are both objects of their respective classes.

Deployment

Deployment diagrams are used to visualize the relationship between software and hardware. To be more specific, with deployment diagrams, you can build a physical model of how software components (artifacts) are deployed on hardware components known as nodes.

A typical simplified deployment pattern for a web application would include:

  1. Nodes (application server and database server).
  2. Artifacts client application schema and database.

The package diagram is similar to the macros for the UML deployment diagrams we explained above. Various packages contain nodes and artifacts. They group diagrams and model components into groups, much like a namespace encapsulates different names that are somewhat related. Ultimately, a package can also be created by several other packages to represent more complex systems and behavior.

The main purpose of a package diagram is to show the relationships between the various major components that make up a complex system. Programmers find this abstraction opportunity good advantage for using package diagrams, especially when some details may be left out of the picture.

Like any other thing in life, getting something right takes the right tools. To document software, processes or systems, use tools that offer UML annotations and diagram templates. There are various software documentation tools that can help you draw a diagram.

They usually fall into the following main categories:

  1. Paper and pen are easy. They take paper and pen, open the UML syntax code from the Internet, and draw any type of diagram that is needed.
  2. Online Tools - There are several online applications that you can use to create your chart. Most of them offer paid subscription or a limited number of diagrams at a free level.
  3. Free online tools are almost the same as paid ones. The main difference is that the paid ones also offer tutorials and ready-made templates for specific diagrams.
  4. A desktop application is a typical desktop application to use for diagrams and just about any other diagram is Microsoft Visio. It offers advanced features and functionality. The only downside is that you have to pay for it.

Thus, it is quite clear that the UML is an important aspect associated with the development of object-oriented software. It uses graphical notation to create visual models of system programs.

The UML is a general-purpose graphical modeling language for specifying, visualizing, designing, and documenting all artifacts created in the development of software systems.

There are many good books that describe in detail about the UML (in some places even in great detail), I would like to collect in one place the basic concepts about diagrams, entities and connections between them for quick recall, something like a cheat sheet.

The note uses materials from books: Ivanov D. Yu., Novikov F. A. Unified Modeling Language UML and Leonenkov. UML tutorial.

First, let's decide on the editor. Under Linux, I tried different UML editors, most of all I liked the UMLet, although it is written in Java, it moves very quickly and most of the entity templates are in it. There is also ArgoUML, a cross-platform UML editor, also written in Java, functionally rich, but slows down more.

I settled on UMLet, set it under Arch Linux and Ubuntu:

# for Arch Linux yaourt -S umlet # For Ubuntu sudo apt-get install umlet

In the UML, all entities can be broken down into the following types:

  • structural;
  • behavioral;
  • grouping;
  • annotation;

There are four main types of relationships used in the UML:

Dependency- indicates that changing the independent entity somehow affects the dependent entity. Graphically, a dependency relationship is depicted as a dashed line with an arrow pointing from the dependent entity to the independent entity.

Association- takes place if one entity is directly related to another (or to others - the association can be not only binary). An association is graphically depicted as a solid line with various additions connecting related entities.

Generalization is a relationship between two entities, one of which is a special (specialized) case of the other. Graphically, the generalization is depicted as a line with a triangular, unshaded arrow at the end, directed from the particular (subclass) to the general (superclass).

Implementation- an implementation relation indicates that one entity is an implementation of another. Graphically, the implementation is depicted as a dashed line with a triangular, unshaded arrow at the end, directed from the realizing entity to the realizable one.

V UML 2 is defined 13 types of charts. By standards, each chart should have a box with a rectangle (lower right corner beveled) in the upper left corner, which indicates the chart ID (tag) and title.

Diagrams for depicting the structure of the system:

  • Component diagram (tag component);
  • Deployment diagram (tag deployment);
  • Class diagram (class diagram, tag class);
  • Object diagram (tag object);
  • Internal structure diagram (composite structure diagram, tag class);

Diagrams for depicting system behavior:

  • Interaction diagram (tag timing);
  • Activity diagram (tag activity);
  • Sequence diagram (tag sd);
  • Communication diagram (tag comm);
  • State machine diagram (tag state machine);
  • Interaction overview diagram tag interaction);

Diagrams stand apart:

  • Usage diagram (use case diagram, use case tag);
  • Package diagram (tag package);

Usage diagram

Usage diagram(use case diagram) is the most general representation of the functional purpose of the system.

Considering a use-case diagram as a model of a system, one can associate it with a black box model. Each use case defines a sequence of actions that must be performed by the designed system when it interacts with the corresponding actor.

The use diagram uses two types of basic entities: use cases and actors, between which the following basic types of relationships are established.

Association relation- This relationship establishes what specific role an actor plays when interacting with an instance of a use case. An association relationship is indicated by a solid line between the actor and the use case. This line may have additional legend, such as name and cardinality.

Expansion ratio- defines how the instances of a particular use case relate to a more general use case, the properties of which are determined based on how these instances are combined together. So, if there is an extension relation from use case A to use case B, then this means that the properties of the instance of use case B can be augmented due to the presence of properties in extended use case A.

An extension relationship between use cases is indicated by a dashed line with an arrow (dependency relationship case) pointing away from the use case that is an extension to the original use case.

Generalization relation serves to indicate the fact that a certain use case A can be generalized to use case B. In this case, option A will be a specialization of option B. In this case, B is called an ancestor or parent in relation to A, and option A is a descendant in relation to option use of V.

Graphically, this relationship is indicated by a solid line with an open triangle arrow that indicates the parent use case.

A generalization relationship between use cases is used when it is necessary to note that child use cases have all the attributes and behaviors of the parent use cases.

Inclusion ratio between two use cases indicates that some specified behavior for one use case is included as a composite component in the behavior sequence of the other use case.

The inclusion relationship from use case A to use case B indicates that each instance of option A includes the functionality specified for option B.

Graphically, this relationship is denoted by a dashed line with an arrow (dependency relationship case) pointing from the base use case to the included use case.

Class diagram

Class diagram(class diagram) is the main way to describe the static structure of a system.

On a class diagram, one main type of entities is used: classes (including numerous special cases of classes: interfaces, primitive types, association classes, etc.), between which the following basic types of relations are established: dependencies, associations, generalizations, implementations.

Addiction relationship generally indicates some semantic relationship between two model elements or two sets of such elements that is not an association, generalization, or implementation relationship. A dependency relationship is used in a situation where some change in one element of the model may require a change in another dependent element in the model.

A dependency relationship is graphically depicted with a dotted line between the corresponding elements with an arrow at one of its ends, with the arrow pointing from the dependency client class to the independent or source class.

Above the arrow there may be special keywords(stereotypes):

  • "access" - serves to indicate the accessibility of public attributes and operations of the source class for client classes;
  • "bind" - the client class can use some template for its subsequent parameterization;
  • "derive" - ​​the attributes of the client class can be computed from the attributes of the source class;
  • "import" - public attributes and operations of the source class become part of the client class, as if they were declared directly in it;
  • "refine" - indicates that the client class serves as a refinement of the source class for historical reasons, when it appears Additional Information while working on a project.

Association relation corresponds to the existence of some relationship between the classes. This relationship is denoted by a solid line with additional special characters that characterize individual properties of a particular association. As additional special characters the name of the association as well as the names and multiplicity of the role classes of the association can be used. The name of the association is an optional element of its designation.

Aggregation ratio takes place between several classes in the event that one of the classes is a certain entity that includes other entities as constituent parts. It is used to represent part-to-whole system relationships.

Composition relation is a special case of an aggregation relation. This relationship serves to highlight a special form of the relationship "part-whole", in which the constituent parts, in a sense, are inside the whole. The specificity of the relationship between them lies in the fact that the parts cannot act in isolation from the whole, that is, with the destruction of the whole, all its component parts are destroyed.

Generalization relation is a relationship between a more general element (parent or ancestor) and a more private or special element (child or descendant). When applied to a class diagram, this relationship describes the hierarchical structure of classes and the inheritance of their properties and behavior. It is assumed that the descendant class has all the properties and behavior of the ancestor class, and also has its own properties and behavior that the ancestor class does not have.

Automaton diagram

Automaton diagram(state machine diagram) or state diagram in UML 1 (state chart diagram) is one way to describe behavior in UML in detail. In essence, automaton diagrams, as the name suggests, are a graph of states and transitions of a finite automaton loaded with many additional details and details.

A state diagram describes the process of changing the states of only one class, or rather, one instance of a certain class, that is, it models all possible changes in the state of a particular object. In this case, a change in the state of an object can be caused by external influences from other objects or from the outside. It is to describe the reaction of an object to such external influences that state diagrams are used.

On the automaton diagram, one main type of entity is used - states, and one type of relationship - transitions, but for both, many varieties, special cases and additional notations are defined. The automaton represents the dynamic aspects of the modeled system in the form of a directed graph, the vertices of which correspond to states, and the arcs correspond to transitions.

Initial state is a special case of a state that does not contain any internal actions (pseudo states). The default object is in this state at the initial moment in time. It serves to indicate in the state diagram the graphics area from which the state transition process begins.

Final (final) a state is a special case of a state that also does not contain any internal actions (pseudo-states). The default object will be in this state after the automaton finishes its work at the final moment of time.

Activity diagram

When modeling the behavior of a designed or analyzed system, it becomes necessary not only to represent the process of changing its states, but also to detail the features of the algorithmic and logical implementation of the operations performed by the system.

Activity diagram(activity diagram) is another way of describing behavior that visually resembles the good old flowchart of the algorithm. Used to simulate the process of performing operations.

The main direction of using activity diagrams is to visualize the peculiarities of the implementation of class operations, when it is necessary to present algorithms for their execution.

In the activity diagram, one main type of entity is used - action, and one type of relationship - transitions (transfers of control). Also used are such constructions as forks, merges, joins, branches. Recommended as a name simple action use a verb with explanatory words.

Sequence diagram

Sequence diagram(sequence diagram) is a way to describe system behavior "by examples".

In fact, a sequence diagram is a record of a protocol of a specific session of the system operation (or a fragment of such a protocol). In object-oriented programming, the most essential run-time is the transfer of messages between communicating objects. It is the sequence of sending messages that is displayed on this diagram, hence the name.

In the sequence diagram, one main type of entity is used - instances of interacting classifiers (mainly classes, components and actors), and one type of relationship - the links through which messages are exchanged.

Possible message types (image taken from larin.in):

Communication diagram

Communication diagram(communication diagram) - a way of describing behavior, semantically equivalent to a sequence diagram. In fact, this is the same description of the message exchange sequence of interacting classifier instances, only expressed in other graphical means.

Thus, in the communication diagram, as well as in the sequence diagram, one main type of entity is used - instances of interacting classifiers and one type of relationship - links. However, the emphasis here is not on time, but on the structure of links between specific instances.

Component diagram

Component diagram(component diagram) - shows the relationship between modules (logical or physical) that make up the simulated system.

The main type of entities in a component diagram are the components themselves, as well as the interfaces through which the relationship between the components is indicated. In a component diagram, the following relationships apply:

  • implementations between components and interfaces (a component implements an interface);
  • dependencies between components and interfaces (a component uses an interface);

Placement diagram

Placement diagram(deployment diagram), along with displaying the composition and relationships of system elements, shows how they are physically located on computing resources at runtime.

In the placement diagram, in comparison with the component diagram, two types of entities are added: an artifact, which is the implementation of a component and a node (it can be either a classifier describing the type of a node, or a specific instance), as well as an association relationship between nodes, showing that nodes physically connected at runtime.

Object diagram

Object diagram(object diagram) - is an instance of a class diagram.

On the object diagram, one main type of entity is used: objects (class instances), between which specific relationships are indicated (most often, association instances). Object diagrams are of an auxiliary nature - in fact, they are examples (one might say, memory dumps) showing what objects are and the connections between them at some specific moment in the functioning of the system.

Internal structure diagram(composite structure diagram) is used for a more detailed presentation of structural classifiers, primarily classes and components.

The structural classifier is depicted as a rectangle, in the upper part of which is the name of the classifier. Inside are the parts. There can be several parts. Parts can interact with each other. This is indicated using connectors of various kinds. The location on the outer edge of the part to which the connector attaches is called a port. Ports are also located on the outer edge of the structural classifier.

Interaction overview diagram An interaction overview diagram is a type of activity diagram with an extended syntax: interaction use links defined by sequence diagrams can act as elements of an interaction overview diagram.

Synchronization diagram

Synchronization diagram(timing diagram) is a special form of sequence diagram, in which special attention is paid to changing the states of different instances of classifiers and their timing.

Package diagram

Package diagram(package diagram) is the only tool that allows you to manage the complexity of the model itself.

The main elements of the notation are packages and dependencies with different stereotypes.

Entity-relationship model (ER-model)

Analogue class diagrams(UML) maybe ER model, which is used in the design of databases (relational model).

Entity-relationship model (ER-model) is a data model that allows you to describe conceptual schemas of the domain. The ER model is used in high-level (conceptual) database design. With its help, it is possible to highlight the key entities and designate the connections that can be established between these entities. wikipedia

Any fragment of the subject area can be represented as a set of entities, between which there are a number of connections.

Basic concepts:

The essence(entity) is an entity that can be identified in some way that distinguishes it from other entities, for example CLIENT 777... An entity is actually a set of attributes.

Entity set(entity set) - a set of entities of the same type (with the same properties).

Connection(relationship) is an association established between multiple entities.

Domain(domain) - a set of values ​​(scope) of an attribute.

There are three types of binary links:

  • one to one- a single instance of an entity of one class is associated with a single instance of an entity of another class, for example, HEAD - DEPARTMENT;
  • 1 to N or one to many- a single instance of an entity of one class is associated with many instances of an entity of another class, for example, DEPARTMENT - EMPLOYEE;
  • N to M or many to many- many instances of an entity of one class are associated with many instances of an entity of another class, for example, EMPLOYEE - PROJECT;
    • A glossary of basic UML concepts

    Object- an entity that is unique and encapsulates state and behavior.

    Class- a description of a set of objects with common attributes that determine state and operations that determine behavior.

    Interface- a named set of operations defining a set of services that can be requested by a consumer and provided by a service provider.

    Collaboration- a set of objects that interact to achieve a goal.

    Actor- an entity that is outside the modeled system and directly interacts with it.

    Component- a modular part of the system with a well-defined set of required and provided interfaces.

    Artifact- an item of information that is used or generated in the process of software development. In other words, an artifact is a physical unit of implementation that is derived from a model element (such as a class or component).

    Node- a computing resource on which artifacts are located and, if necessary, are executed.

    Behavioral entities are intended to describe behavior. There are only two basic behavioral entities: state and action.

    State- a period in the life cycle of an object, being in which the object satisfies a certain condition and carries out its own activity or waits for the occurrence of some event.

    Action- primitive atomic computation.

    Machine is a package that defines a set of concepts necessary to represent the behavior of a modeled entity in the form of a discrete space with a finite number of states and transitions.

    Classifier is a descriptor of a set of objects of the same type.

    Additional reading

    • Fowler M. UML. Fundamentals, 3rd Edition
    • Booch G., Rambeau D., Jacobson I. UML. User guide