Basic diagrams of the UML language. UML diagram. UML diagram types Line types are used in uml diagrams

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 graphical notations to create an abstract model of the system. 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 separate code based on it.

Why is it needed?

UML does not end with modeling all kinds of software. Also given language it is actively used today for modeling various business processes, conducting systems engineering, as well as displaying organizational structures.

Using the UML, software developers can provide 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 focus 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 structural 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. UML component diagram as such can use all kinds 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 to simulate running nodes, as well as all kinds of artifacts that have been 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 for 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 in itself. It is worth noting that different elements can provide other UML diagrams (examples: packages and 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, as well as 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 going 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 calculations... Among other things, they simulate all kinds of technological procedures.

Automaton diagram

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

A finite 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 the customer, 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 in different ways, and, if necessary, with the required degree of accuracy, you can transform one into 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 begins with the original message 1.0, and then continues in the direction in which 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 a communication diagram more clearly shows which elements each individual element interacts with, while a sequence diagram more clearly shows 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 that reflect the flow 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 diagrams UML which are a type of activity diagram and include both Sequence elements and control flow constructs.

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

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 ​​that are 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. The inaccuracy of the 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 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 with any standard notation system, the 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 final goal, it is necessary to select the applicable capabilities of that language. In addition, possible ways of limiting the scope of UML use 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.

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 created information system;

· 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 message exchange 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 - to model the behavior of a system within different use cases, or to model 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 in the process of discussing with the user those functions that he would like to implement in a given information system. In 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 on the diagram only when they really need some use cases. In the UML, actors are represented as shapes:

Fig. 3. Actor (actor)

Actors are divided into three main types:

· 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 unidirectional 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 shows 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 the sequence diagram, the object is depicted as a rectangle, from which a dashed line is drawn down vertical line... 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 shown 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 arrow of the message 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 a collaboration diagram, as in a sequence diagram, arrows indicate messages exchanged within a given use case. 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 whose nodes are elements of the static structure of a project (classes, interfaces), and arcs are the relationships between nodes (associations, inheritance, dependencies).

The class diagram depicts the following elements:

· Package (package) - a set of elements of the model, 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) with 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 diagrams, a class is depicted as a rectangle with a solid border, separated 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. it screen forms, reports, interfaces to hardware (such as printers or scanners), and interfaces to 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 control class is responsible for coordination, but 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 this attribute is generic, 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-related 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 the message in the 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 are necessary for it to perform its responsibilities, but about which other classes should not know anything. 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. Reflexive messages will be auxiliary operations.

2. Consider control operations. You may 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 a 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, bidirectional 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 in the opposite direction, 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.

Addiction is portrayed dotted line drawn between two chart elements, and the element anchored to the end of the arrow is considered to depend 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 the connection between the whole and its part. 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 a unified graphical modeling language for describing, visualizing, designing, and documenting OO systems. UML is designed to support the process of modeling software systems based on the OO approach, to organize the relationship of conceptual and software concepts, to reflect the problems of scaling complex systems. Models in UML are used at all stages of the software system life cycle, from business analysis to system maintenance. Different organizations can apply UML as they see fit, depending on their problem areas and technologies used.

A brief history of the UML

By the mid-90s, several dozen OO modeling methods were proposed by various authors, each of which used its own graphical notation. Moreover, any of these methods had their own strengths, but did not allow to build a sufficiently complete model of the PS, to show it "from all sides", that is, all the necessary projections (See article 1). In addition, the lack of an OO modeling standard made it difficult for developers to choose the most appropriate method, which prevented the widespread use of OO approach to software development.

At the request of the Object Management Group (OMG) - the organization responsible for the adoption of standards in the field of object technologies and databases, the urgent problem of unification and standardization was solved by the authors of the three most popular OO methods - G. Buch, D. Rambo and A. Jacobson, who united efforts created the UML 1.1 version, approved by the OMG in 1997 as a standard.

UML is a language

Any language consists of a vocabulary and rules for combining words to obtain meaningful constructions. So, in particular, programming languages ​​are arranged, such is the UML. Its distinctive feature is that the language dictionary is formed by graphic elements. Each graphic symbol has a specific semantics, so a model created by one developer can be unambiguously understood by another, as well as a software tool that interprets the UML. From this, in particular, it follows that a PS model represented in UML can be automatically translated into an OO programming language (such as Java, C ++, VisualBasic), that is, if there is a good visual modeling tool that supports UML, building the model , we will receive a preparation of the program code corresponding to this model.

It should be emphasized that the UML is a language, not a method. It explains what elements to build models from and how to read them, but it says nothing about which models should be developed and in what cases. To create a method based on UML, it is necessary to supplement it with a description of the software development process. An example of such a process is the Rational Unified Process, which will be discussed in subsequent articles.

UML vocabulary

The model is represented in the form of entities and relationships between them, which are shown in diagrams.

Entities Are abstractions that are the main elements of models. There are four types of entities - structural (class, interface, component, use case, cooperation, node), behavioral (interaction, state), grouping (packages), and annotation (comments). Each type of entity has its own graphical representation... Entities will be discussed in detail when examining diagrams.

Relationship show various relationships between entities. The UML defines the following types of relationships:

• Addiction shows such a relationship between two entities, when changing one of them - independent - can affect the semantics of the other - dependent. Dependency is depicted by a dashed arrow pointing from the dependent entity to the independent entity.
• Association Is a structural relationship showing that objects in one entity are related to objects in another. An association is shown graphically as a line connecting the entities being linked. Associations are used to navigate between objects. For example, the association between the "Order" and "Product" classes can be used to find all the goods specified in a particular order - on the one hand, or to find all orders in which there is a given product - on the other. It is clear that the corresponding programs must implement a mechanism for such navigation. If only one direction is required to navigate, it is indicated by an arrow at the end of the association. A special case of an association is aggregation - a relation of the form "whole" - "part". Graphically, it is highlighted with a diamond at the end near the entity-whole.
• Generalization Is a relationship between a parent entity and a descendant entity. Essentially, this relationship reflects the inheritance property for classes and objects. The generalization is shown as a line ending with a triangle pointing towards the parent entity. The child inherits the structure (attributes) and behavior (methods) of the parent, but at the same time it can have new structure members and new methods. UML allows multiple inheritance when an entity is associated with more than one parent entity.
• Implementation- the relationship between the entity that defines the specification of behavior (interface) with the entity that defines the implementation of this behavior (class, component). This relationship is commonly used in component modeling and will be described in more detail in subsequent articles.

Diagrams. The UML provides the following diagrams:

• Diagrams describing system behavior:
• State diagrams,
• Activity diagrams,
• Object diagrams,
• Sequence diagrams,
• Collaboration diagrams
• Diagrams describing the physical implementation of the system:
• Component diagrams
• Deployment diagrams

Model control view. Packages.

We have already said that in order for a model to be well understood by a person, it is necessary to organize it hierarchically, leaving a small number of entities at each level of the hierarchy. UML includes a means of organizing the hierarchical representation of the model - packages. Any model consists of a set of packages that can contain classes, use cases, and other entities and diagrams. A package can include other packages to create hierarchies. There are no separate package diagrams in the UML, but they may appear in other diagrams. The package is displayed as a rectangle with a tab.

What the UML provides.

• a hierarchical description of a complex system by allocating packages;
• formalization of functional requirements for the system using the apparatus of use cases;
• detailing the requirements for the system by building diagrams of activities and scenarios;
• highlighting data classes and building a conceptual data model in the form of class diagrams;
• highlighting classes that describe the user interface and creating a screen navigation scheme;
• description of the processes of interaction of objects when performing system functions;
• description of the behavior of objects in the form of diagrams of activities and states;
• description of software components and their interactions through interfaces;
• a description of the physical architecture of the system.

And the last ...

Despite all the attractiveness of UML, it would be difficult to use it in real software modeling without visual modeling tools. Such tools allow you to quickly present diagrams on the display screen, document them, generate blank program codes in various OO programming languages, and create database schemas. Most of them include the possibility of reengineering program codes - restoring certain projections of the SS model by automatically analyzing the source codes of programs, which is very important to ensure the consistency of the model and codes and when designing systems that inherit the functionality of predecessor systems.

All UML diagrams can be roughly divided into two groups, the first of which is general diagrams. General diagrams are practically independent of the subject of modeling and can be used in any software project without regard to the subject area, solution area, etc.

1.5.1. Usage diagram

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

The use diagram is intended to answer the main modeling question: what is the system doing in the outside world?

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

• the association between the actor and use case 3;
• generalization between actors 4;
• generalization between use cases 5;
• dependencies ( different types) between use cases 6.

The usage diagram, like any other, may contain comments 7. Moreover, it is highly recommended to do this to improve the readability of the diagrams.

The basic elements of the notation used in the usage diagram are shown below. A detailed description is given in section 2.2.

1.5.2. Class diagram

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

This is not surprising, since UML is primarily an object-oriented language, and classes are the main (if not the only) building blocks.

On a class diagram, one main type of entities is used: classes 1 (including numerous special cases of classes: interfaces, primitive types, association classes, and many others), between which the following basic types of relations are established:

• association between classes 2 (with many additional details);
• generalization between classes 3;
• dependencies (of various types) between 4 classes and between classes and interfaces.

Some of the elements of the class diagram notation are shown below. A detailed description is given in chapter 3.

1.5.3. Automaton diagram

Automaton diagram(state machine diagram) is one of the ways to describe in detail the behavior in the UML based on explicitly highlighting states and describing transitions between states.

In essence, automaton diagrams, as the name suggests, are a state transition graph (see Chapter 4), loaded with a lot of additional details and details.

On the automaton diagram, one main type of entities is used - states 1, and one type of relations - transitions 2, but for both, many varieties, special cases and additional designations are defined. It makes no sense to list them all in the introductory survey.

A detailed description of all the variations of the automaton diagrams is given in section 4.2, and the following figure shows only the basic elements of the notation used in the automaton diagram.

1.5.4. Activity diagram

Activity diagram(activity diagram) - a way to describe behavior based on the indication of control flows and data flows.

An activity diagram is another way of describing behavior that visually resembles a good old-fashioned flowchart. However, due to the modernized notation, consistent with the object-oriented approach, and most importantly, due to the new semantic component (free interpretation of Petri nets), the UML activity diagram is a powerful tool for describing the behavior of a system.

In the activity diagram, one main type of entity is used - activity 1, and one type of relationship - transitions 2 (control and data transfers). Also used are such constructions as forks, merges, joins, branches 3, which are similar to entities, but in fact they are not, but are graphical way images of some special cases of multiplace relations. The semantics of activity diagram elements is covered in detail in Chapter 4. The basic elements of the notation used in the activity diagram are shown below.

1.5.5. Sequence diagram

Sequence diagram(sequence diagram) is a way to describe the behavior of a system based on an indication of the sequence of transmitted messages.

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 1 (mainly classes, components and actors), and one type of relationship - links 2, through which messages are exchanged 3. There are several ways to send messages, which in graphical notation are distinguished by the type of arrow corresponding to the relation.

An important aspect of the sequence diagram is the explicit display of the passage of time. Unlike other types of diagrams, except perhaps synchronization diagrams, in a sequence diagram, not only the presence of graphic relationships between elements is important, but also the relative position of elements on the diagram. Namely, it is assumed that there is an (invisible) time axis, by default, directed from top to bottom, and the message that is sent later is drawn below.

The time axis can be directed horizontally, in this case it is considered that time flows from left to right.

The following illustration shows the basic elements of notation used in a sequence diagram. To designate the interacting objects themselves, the standard notation is used - a rectangle with the name of the classifier instance. The dotted line extending from it is called the lifeline 4. This is not a designation of a relationship in the model, but a graphic commentary designed to guide the reader's eye in the right direction. The figures in the form of narrow stripes superimposed on the lifeline are also not images of the modeled entities. This is a graphic commentary showing the time intervals during which the object owns the execution occurrence 5 or, in other words, the object's activation takes place. Combined Fragment Steps 6 allow a sequence diagram to reflect the algorithmic aspects of an interaction protocol. For more details on sequence diagram notation, see Chapter 4.

1.5.6. 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 messaging sequence of interacting classifier instances, only expressed by others. graphically... Moreover, most tools can automatically convert sequence diagrams to communication diagrams and vice versa.

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

The figure shows the basic elements of notation used in a communication diagram. To designate the interacting objects themselves, the standard notation is used - a rectangle with the name of the classifier instance. The relative position of elements on the cooperation diagram does not matter - only the links (most often instances of associations) are important, along which messages are transmitted 3. Hierarchical decimal numbering is used to display the ordering of messages over time.

1.5.7. 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 the component diagram are the components 1 themselves, as well as the interfaces 2, 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 (component uses an interface) 3.

The figure shows the basic elements of notation used in a component diagram. A detailed description is given in chapter 3.

1.5.8. 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.

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

The figure shows the basic elements of the notation used in the placement diagram. To show that one entity is part of another, either the "deploy" dependency relationship 5 is applied, or the shape of one entity is placed inside the shape of another entity 6. A detailed description of the diagram is given in chapter 3.

What is UML?

If you look at the pictures in search engines, then it becomes clear that UML- this is something about diagrams, arrows and squares. What's important is that the UML is translated as Unified Modeling Language... The word Unified is important here. That is, our pictures will be understood not only by us, but also by others who know the UML. It turns out this is such an international language for drawing diagrams.

As Wikipedia says

UML is a graphical description language for object modeling in software development, business process modeling, systems engineering, and display of organizational structures.

Application

But what if you want to draw yourself, and even there is no Ultimate version of Idea? If we are using IntelliJ Idea Community Edition, then we have no other choice. To do this, you need to understand how such a UML diagram works. First, we need to install Graphviz. It is a set of graph visualization utilities. It is used by the plugin that we will be using. After installation, you need to add the directory bin from the installed directory Graphviz to environment variable PATH... After that, in IntelliJ Idea, select File -> Settings from the menu. In the "Settings" window, select the "Plugins" category, click the "Browse repositories" button and install the PlantUML integration plugin. What is so good about this PlantUML? It uses for UML descriptions a graph description language called " dot"and this allows it to be more universal, since this language is used not only by PlantUML. Moreover, everything we do below we can do not only in the IDE, but also in the online service planttext.com. After installing the PlantUML plugin in we will be able to create UML diagrams through "File" -> "New". Let's create a diagram of the "UML class" type. During this, a template with an example is automatically generated. Let's delete its content and create our own, armed with an article from Habr: Class relations - from UML to code.And to understand how to depict it in the text, take the PlantUML manual: plantuml class-diagram.In it, at the very beginning, there is a plate with how to describe the connections:

As for the links themselves, we can still peep here: "Relations between classes in the UML. Examples". Based on these materials, let's start creating our UML diagram. Add the following content describing the two classes: @startuml class ArrayList () class LinkedList () @enduml To see the result in Idea, select View -> Tool Windows -> PlantUML. We just get two squares representing the classes. As we know, both of these classes implement the List interface. This class relation is called realization. An arrow with a dashed line is used to depict such a connection. Let's represent it: interface List List< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о package private array of elements: ~ Object elementData Now we want to show that the ArrayList contains some objects. In this case, the link type will be - aggregation(aggregation). The aggregate in this case is ArrayList, since it contains other objects. We choose aggregation because the objects in the list can live without the list: they are not integral parts of it. Their lifetime is not tied to the lifetime of the list. Aggregate from Latin translates as "assembled", that is, something made up of something. For example, in life, there is a pumping unit, which consists of a pump and an engine. The unit itself can be disassembled, leaving something of its component parts. For example, to sell or put in another unit. So it is on the list. And this is expressed in the form of an empty diamond at the unit and a continuous line. Let's depict it like this: class Object () ArrayList o- Object Now we want to show that, unlike ArrayList, the LinkedList class contains Node - containers that refer to stored data. In this case, Nodes are part of the LinkedList itself and cannot live separately. Node is not directly stored content, but only contains a link to it. For example, when we add a line to the LinkedList, we add a new Node that contains a link to that line, as well as a link to the previous and next Node. This type of communication is called composition(Composition). To display the composite (the one that consists of parts), a painted robot is drawn, a continuous line leads to it. Now let's write this in the form of a textual display of the link: class Node () LinkedList * - Node And now we need to learn how to display another important type of link - addiction(dependency relationship). It is used when one class uses another, and the class does not contain the used class and does not inherit from it. For example, LinkedList and ArrayList both know how to create a ListIterator. We represent this as arrows with a dotted line: class ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:

You can detail as much as necessary. All designations are listed here: "PlantUML - Class Diagram". In addition, there is nothing supernatural in drawing such a scheme, and when working on your tasks, you can quickly draw it by hand. This will develop skills in thinking through the architecture of your application and will help you identify flaws in the class structure early, rather than when you have already spent the day implementing the wrong model. I think this is a good reason to give it a try?)

Automation

Since Maven is not the focus of this article, you can find answers to your Maven questions at the Maven Users Center. In the generated project, open the project description file for editing, pom.xml... Copy the content from the uml-java-docklet installing description into it. The artifact used in the description could not be found in the Maven Central repository. But it worked for me with this: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0. That is, you just need to replace in that description groupId with " info.leadinglight" on " com.chfourie"and put the version" 1.0.0 ". After that we can execute in the directory where the file is located pom.xml these commands: mvn clean install and mvn javadoc: javadoc. Now, if we open the generated documentation (explorer target \ site \ apidocs \ index.html), we will see the UML diagram. By the way, the implementation is already displayed correctly here)

Conclusion