Types of UML Diagrams

All UML diagrams can be 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 usage diagram is designed to answer the main modeling question: what does the system do in the outside world?

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

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

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

The main 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) is 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 block.

A class diagram uses one basic type of entity: classes 1 (including numerous special cases of classes: interfaces, primitive types, association classes, and many others), between which the following basic types of relationships are established:

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

Some of the notation used in a class diagram is shown below. A detailed description is given in Chapter 3.

1.5.3. Machine diagram

Machine diagram(state machine diagram) is one of the ways to describe behavior in detail in UML based on the explicit identification of states and description of transitions between states.

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

On an automaton diagram, one main type of entity is used - states 1, and one type of relationship - transitions 2, but for both of them many varieties, special cases and additional notations are defined. There is no point in listing them all in an introductory review.

A detailed description of all variations of automaton diagrams is given in section 4.2, and the following figure shows only the main 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 specifying control flows and data flows.

An activity diagram is another way to describe behavior that is visually reminiscent of a good old algorithm 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 the system.

The activity diagram uses one main type of entity - action 1, and one type of relationship - transitions 2 (transfers of control and data). Also used are such constructions as forks, mergers, connections, branches 3, which are similar to entities, but in fact they are not, but are a graphical way of depicting some special cases of multi-place relations. The semantics of activity diagram elements is discussed in detail in Chapter 4. The main elements of notation used in an activity diagram are shown below.

1.5.5. Sequence diagram

Sequence diagram(sequence diagram) is a way of describing the behavior of a system based on indicating the sequence of transmitted messages.

In fact, a sequence diagram is a record of the protocol of a specific session of the system (or a fragment of such a protocol). In object-oriented programming, the most important thing at runtime is the passing of messages between communicating objects. It is the sequence of message sending that is displayed in this diagram, hence the name.

A sequence diagram uses one main type of entity - instances of interacting classifiers 1 (mainly classes, components and actors), and one type of relationship - connections 2 along which messages are exchanged 3. There are several ways to send messages, which in graphical notation differ in the type of arrow corresponding to the relation.

An important aspect of a sequence diagram is to clearly show the passage of time. Unlike other types of diagrams, except perhaps synchronization diagrams, in a sequence diagram it is important not only the presence of graphic connections between elements, but also the relative position of the 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 which case time is considered to flow from left to right.

The following figure shows the basic notation used in a sequence diagram. To designate the interacting objects themselves, a standard notation is used - a rectangle with the name of the classifier instance. The dotted line coming out of it is called the lifeline 4. This is not a representation of a relationship in the model, but a graphical comment designed to guide the reader of the diagram in the right direction. Figures in the form of narrow stripes superimposed on the life line are also not images of the simulated entities. This is a graphical comment showing the periods of time during which the object owns the control flow (execution occurrence) 5 or, in other words, the activation of the object takes place. Combined fragment steps 6 allow the sequence diagram to reflect the algorithmic aspects of the interaction protocol. For other details of sequence diagram notation, see Chapter 4.

1.5.6. Communication diagram

Communication diagram(communication diagram) is a way of describing behavior that is semantically equivalent to a sequence diagram.

In fact, this is the same description of the sequence of message exchange of interacting instances of classifiers, only expressed by other graphical means. 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 - connections 2. However, here the emphasis is not on time, but on the structure of connections between specific instances.

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

1.5.7. Component Diagram

Component Diagram(component diagram) - shows the relationships between the modules (logical or physical) that make up the modeled system.

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

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

The figure shows the main elements of the 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 connections of system elements, shows how they are physically located on computing resources at runtime.

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

The figure shows the main elements of the notation used in a layout diagram. To show that one entity is a part of another, either a "deploy" dependency relation is applied 5 or a figure of one entity is placed inside a figure of another entity 6 . A detailed description of the diagram is given in Chapter 3.

Creating additional visual and documentary support for a program is a labor-intensive and tedious process: it takes a lot of time and seems completely unnecessary if the software architecture is simple or reference. However, in practice, programmers are not always faced with such tasks.

Why UML didn't take off

“Today programming is not an engineering science, but applied mathematics. At the same time, programmers immediately learn to write code,” explains Anatoly Shalyto, head of the Department of Programming Technologies at ITMO University.

People tried to work with UML, hoping that it would become a kind of “silver bullet”, but it did not gain widespread popularity. Researchers identify three main obstacles that have prevented the widespread adoption of state diagrams as a common means of describing algorithms and complex program behaviors.

Firstly, to describe behavior, in addition to state diagrams, it was proposed to use other types of diagrams, but the rules defining their interaction were not regulated.

“Many people think the language is too long,” says researcher and entrepreneur Jordi Cabot. “This is due to the large number of diagrams available in UML.”

A similar fate awaited many other solutions, which, however, are not full-fledged alternatives to UML. We are talking about business process modeling notation (BPMN), entity-relationship models (ERM), data flow diagrams (DFD), state diagrams, etc. As Cris Fuhrman notes, all this is nothing more than communication tools.

Transition to slot machines

Automatic programming is an approach that can facilitate the specification generation process. During operation, graphs are created in which, under the influence of external or any other input influences, transitions between states are made and output “pulses” are formed. To do this, a text version of the technical specification is first generated, in which the customer prescribes the detailed operation of the desired solution.

After this, the symbols of input and output influences, sources and receivers of information are announced, and then a diagram is drawn. Transition graphs allow the customer to better understand what the programmer will do.

Having a connection diagram and a transition diagram, using a formal transformation, you can build a code that implements an automaton in a programming language. The specifications then become part of the system design documentation. Project documentation is compiled in natural language and usually contains a statement of the problem, a description of the structure and behavior of the system, and examples of its use.

Automatic description in OOP

Mapping a separate class to each control object ensures that the efforts of developers to identify these objects at the modeling stage do not disappear at the implementation stage. Moreover, each request or command has access only to a strictly defined part of the computational state.

In general, the process of designing a system with complex behavior can be described as follows:

1. Carrying out object decomposition, when the system is divided into many independent interacting entities.
2. Mapping entities to classes, defining class interfaces and relationships.
3. Isolating those entities that have complex behavior - it is for their description that the automatic approach will be used.
4. Setting a set of control states for each entity. Requests and commands are mapped to the input and output variables of the control machine, and interface components are mapped to its events. The control machine itself is built on their basis.
5. Implementation of manual classes in the selected object-oriented language. Code generation can be done either automatically or manually.

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 based on the OO approach, organize the relationship of conceptual and program concepts, and reflect the problems of scaling complex systems. UML models are used at all stages of the software life cycle, from business analysis to system maintenance. Different organizations may use UML as they see fit, depending on their problem areas and the technologies they use.

A Brief History of UML

By the mid-90s, various authors had proposed several dozen OO modeling methods, each of which used its own graphical notation. At the same time, any of these methods had its strengths, but did not allow building a sufficiently complete model of the PS, showing 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 suitable method, which prevented the widespread adoption of the 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. Butch, D. Rambo and A. Jacobson, who combined efforts created version UML 1.1, approved by OMG in 1997 as a standard.

UML is a language

Any language consists of a vocabulary and rules for combining words to create meaningful constructions. This is, in particular, how programming languages ​​are structured, such as UML. Its distinctive feature is that the language dictionary is formed by graphic elements. Each graphic symbol has a specific semantics associated with it, so a model created by one developer can be clearly understood by another, as well as by a software tool that interprets UML. From here, in particular, it follows that a software model presented 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, having built the model , we will also receive a sample program code corresponding to this model.

It should be emphasized that UML is a language, not a method. It explains what elements to create models from and how to read them, but 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 Dictionary

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, collaboration, 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 studying the diagrams.

Relationship show various connections between entities. UML defines the following relationship types:

• Addiction shows such a connection between two entities when a change in one of them - independent - can affect the semantics of the other - dependent. Dependency is represented by a dotted arrow directed from the dependent entity to the independent one.
• Association is a structural relationship showing that the objects of one entity are related to the objects of another. Graphically, an association is shown as a line connecting the associated entities. Associations serve to navigate between objects. For example, the association between the classes “Order” and “Product” can be used to find all products specified in a specific order, on the one hand, or to find all orders that contain this product, on the other. It is clear that the corresponding programs must implement a mechanism that provides such navigation. If navigation in only one direction is required, it is indicated by an arrow at the end of the association. A special case of association is aggregation - a relationship of the form “whole” - “part”. Graphically, it is highlighted with a diamond at the end near the essence-whole.
• Generalization is the relationship between a parent entity and a child entity. Essentially, this relationship reflects the property of inheritance for classes and objects. The generalization is shown as a line ending with a triangle directed 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 elements and new methods. UML allows multiple inheritance, where an entity is related to more than one parent entity.
• Implementation– the relationship between an entity that defines a specification of behavior (interface) with an entity that defines the implementation of this behavior (class, component). This relationship is commonly used when modeling components and will be described in more detail in subsequent articles.

Diagrams. UML provides the following diagrams:

• Diagrams describing the behavior of the system:
• 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 humans, 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 a hierarchical representation of a model - packages. Any model consists of a set of packages that may contain classes, use cases, and other entities and diagrams. A package can contain other packages, allowing the creation of hierarchies. UML does not provide separate package diagrams, but they may appear in other diagrams. The package is depicted as a rectangle with a bookmark.

What UML provides.

• hierarchical description of a complex system by identifying packages;
• formalization of functional requirements for the system using the apparatus of use cases;
• detailing system requirements by constructing activity diagrams and scenarios;
• identifying data classes and constructing a conceptual data model in the form of class diagrams;
• identifying 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 object behavior in the form of activity and state diagrams;
• description of software components and their interaction through interfaces;
• description of the physical architecture of the system.

And the last thing...

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

The Unified Modeling Language (UML) can be considered the result of a rather long and not yet completed evolution of modeling and design methodologies.

In the 90s, three object-oriented approaches were most popular:

As a result of the competition between these methods, the authors of the above methodologies created a unified modeling language, UML (Fig. 1), which inherited elements present in other languages. The following is the original terminology of the borrowed/inherited elements of the language of this methodology - the fact is that now there are several options for translating these terms into Russian.

Rice. 1. UML and its predecessors

This unification pursued three main goals:

System modeling, from concept to executable module, using object-oriented techniques;

Resolving scaling problems in complex systems;

Creating a modeling language that can be used by both humans and computers.

The official date for the start of work on UML is considered to be October 1994, when Rambo moved to Rational (now Rational is one of the divisions of IBM Corporation). The latest standard for this language is UML1.3, released in 1999.

UML modeling tools

Is UML a necessary component of RUP? Yes, definitely. But the practice of using UML as a means of describing the modeling and software development process is not limited to RUP. Like any other language, UML is just a tool. RUP provides a number of utilities that make using UML fairly easy, but they are not limited to IBM/Rational products. The following is a non-exhaustive list of some products that support UML:

Rational Rose (Rational Software, Windows 98/NT/2000/XP, Linux Red Hat 6.2, 7.0, Solaris 2.5.1, 2.6, 7, 8, HP-UX 10.20, 11.0, 11.i);

Microsoft Visual Studio .NET Enterprise Architect, Microsoft Visio (Microsoft, platforms: Windows 98/NT/2000/XP/Server 2003);

Describe Enterprise (Embarcadero technologies, platforms: Windows 98/NT/2000/XP);

Together product family (Borland, platforms: Windows 98/NT/2000/XP, Linux, Solaris);

Bold for Delphi (Borland, platforms: Windows 98/NT/2000/XP);

MagicDraw (Magic, Inc., platforms: Windows 98/Me/NT/2000/XP, Solaris, OS/2, Linux, HP-UX, AIX, Mac OS);

QuickUML (ExcelSoftware, platforms: Windows 98/NT/2000/XP) is a good utility for beginners.

Let us also note some OpenSourse products, for example ArgoUML, Novosoft UML Library.

The document, which contains lists of UML-enabled products, manufacturing companies, platforms, and estimated product pricing information, can be found at: http://www.objectsbydesign.com/tools/umltools_byCompany.html.

It should also be noted that, despite the existence of the UML 1.3 standard, the UML implementations supported by these products either have their own features or do not fully follow the standard, so when choosing a modeling tool, you should pay attention to the supported diagram types and syntax features. In addition, the capabilities of forward and reverse engineering (Round-Trip Engineering) vary widely between products. Not all of the above products can support the programming languages ​​Java, C++, CORBA IDL, so you should pay special attention to what model a particular product can generate from your existing code, in what language the code from your UML model can be obtained, and what type should it be?

A table showing which UML diagrams are implemented in which product can be found at: http://www.jeckle.de/umltools.htm.

What is UML used for?

UML is first and foremost a language, and like any language tool, it provides a dictionary and rules for combining words in that dictionary. Here, the vocabulary and rules focus on the conceptual and physical representations of the system. The language dictates how to create and read the model, but does not provide any guidance on what kind of system model to create; this is outside the scope of UML and is the domain of the software development process. In this regard, it seems that UML is quite often associated with RUP one of the possible processes that recommend what models, how and when to create for successful product development.

UML is a visualization language. Writing models in UML has one simple goal - to facilitate the process of transferring information about the system. Each UML symbol has strictly defined semantics, which allows you to avoid interpretation errors (answers to questions like “what did developer X mean when he described the hierarchy of classes Y...”, etc. will be quite transparent).

UML is a language of specifications and precise definitions. In this sense, UML modeling means building models that are accurate, unambiguous, and complete.

UML is a design language. UML is not a visual programming language, but models in UML terms can be mapped to a specific set of object-oriented programming languages. UML provides forward (existing model ® new code) and reverse (existing code ® new model) design capabilities. Quite often, UML modeling tools implement mappings of UML models in code in Java, C++, CORBA, VB, Smalltalk.

UML is a documentation language. The software development process involves not only writing code, but also creating artifacts such as a list of requirements, an architecture description, design, system source code, project planning, tests, a set of prototypes, and product releases. Depending on the culture of product development in a particular company, the degree of formalization of these documents varies significantly, ranging from strictly defined templates and document formats to conversations on an arbitrary topic via e-mail or in person. However, all of these artifacts are critical to a successful product development process. UML provides tools for displaying system requirements, constructing documentation, testing, modeling the necessary actions for project planning and for managing releases delivered to the end user.

Elements of language

The main elements of UML are entities (Thing), relationships (Relationship), diagrams (Diagram). Entities are the core abstractions of a language, relationships link entities together, and diagrams group collections of entities that are of interest.

Entities

Structural entities are nouns of the language (Fig. 2). These include:

classes (Class) is a set of objects that share the same attributes, operations, relationships and semantics. A class implements one or more interfaces and is depicted as a rectangle that includes the class name, names of attributes, operations, and a note;

interfaces is a set of operations that define a class service or components. An interface is graphically represented as a circle and is usually attached to a class or component that implements the interface;

cooperation define interactions and serve to bring together roles and other elements that interact together so that the resulting behavior of an object is greater than the sum of all elements. Depicted as an ellipse with a dotted border;

Use cases description of a set of sequences of actions that are performed by the system and have significance for a specific actor (Actor). Use cases are depicted as an ellipse and are used to structure behavioral entities in the model;

active classes these are classes whose instances are active objects that own a process or flow of control and can initiate control action. The stereotypes of a concrete class are Process and Thread. Graphically, such a class is depicted as a class with a thick border;

components these are physically replaceable parts of the system that provide the implementation of a number of interfaces. A component is a physical representation of logical elements such as classes, interfaces, and collaborations. The domain of components refers to the implementation. Components are shown as a rectangle with labels on the left and usually have only a name and a note;

nodes physical objects that exist during program execution and represent a communication resource that has at least memory, and often a processor. Nodes can contain executable objects and components. The nodes are shown as a cube and have a name and a note.

The data of these seven types of objects are the basic structural objects of UML. There are also variations of these objects, such as actors (Actor), signals (Signal), utilities (Utility - a type of class), processes and threads (Process and Thread - types of an active class), applications (Application), documents (document), files (File), libraries (Library), pages (Page), tables (Table).

Behavioral entities are the dynamic parts of UML models (Figure 3). These include:

Interaction include a set of messages exchanged between specified objects in order to achieve a specified goal. The interaction is described in the context of cooperation and is depicted by a directed line, marked with the name of the operation at the top;

State machines specifications of behavior, which are sequences of states through which an object passes during its life, or interaction in response to occurring events (as well as the object’s response to these events). The automaton is attached to the original element (class, collaboration or method) and serves to determine the behavior of its instances. The machine is depicted as a rectangle with rounded corners.

Grouping Entities these are the organizational components of UML models. These include packages a generalized mechanism for organizing elements into groups. Structural, behavioral, grouping entities can be placed in a package. Packages are purely conceptual entities, as opposed to components that exist at runtime. The package is displayed as a folder with a shortcut at the top and, as a rule, has only a name.

Annotation Entities these are the explanatory components of UML models, which include notes explanatory elements of the language (Fig. 4). They contain the text of the comment and are depicted as a rectangle with a folded corner of the page.

Relationship

The basic relationships between objects that allow the construction of UML blocks include the following (Fig. 5):

dependency this is a semantic relationship between two entities, in which a change in one of them (an independent entity) can affect the semantics of the other (dependent). The types of dependencies that correspond to several types of relationships between objects are listed below:

- abstraction represents a change in the level of abstraction for some concept. As a rule, one of the elements is more abstract, and the second is more concrete, although situations are possible when both elements are two possible variants of a concept that exist at the same level of abstraction. Abstraction dependency includes the following stereotypes (in order of increasing specificity of relationships): trace (Trace), refine (Refine), implement (has its own notation) and derive (Derive),

- Binding associates an element with a template. The arguments required for the template parameters are attached to the binding dependency as a list,

- combination correlates two parts of the classifier description (any element of the model that describes certain features of the structure and behavior of the system) to obtain a complete description of the element,

- permission A dependency (always depicted as a special stereotype) that links a package (or class) to another package (or class) to which it grants permission to use its contents. The permission dependency stereotypes are: Access, Friend, and Import.

- Usage describes a situation where one element requires the presence of another element for proper implementation or operation. Stereotypes of this type of dependency include: Call, Instantiate, Parameter, and Send;

Association a structural relationship that describes a set of connections between classifier objects, where a connection (Link) is a connection between objects that describes the connections between their instances. Associations are like the glue that binds the system together. Without associations, we would simply have a number of classes that are unable to interact with each other. An association may have a name, but the main information about an association should be found at its poles, which describe how each object participates in the association: an association has a list consisting of two or more association poles: each of them defines the role that this one plays classifier in this association. The same classifier can play several roles that are not interchangeable. Each pole of an association describes properties that apply to a particular object in that association, such as how many times one object can appear in relationships (multiplicity). Some properties (such as navigability) apply only to binary associations, although most properties apply to both binary and n-ary associations;

generalization this is a specialization/generalization relationship in which objects of a specialized element (child) can be substituted for objects of a generalized element (parent, ancestor Parent). In the case of generalization of classes, the direct ancestor can be called a superclass, and the direct descendant can be called a subclass;

Realization the relationship between the specification and its software implementation; an indication that behavior is inherited without structure.

We have listed four main relationships. In UML there are also their variants: refinement (Refinement), tracing (Trace), inclusion (Include), extension (Extend).

UML Diagrams

Visualization of the design of the system from various points of view in UML is implemented through diagrams - projections of the system. A diagram is a graphical representation of a set of elements, which is depicted as a connected graph with vertices (entities) and edges (relationships).

Most often, UML views a system from five interrelated perspectives (Figure 6).

Use case view includes user stories that describe the system from the point of view of the end user, analyst, tester. This representation does not define the structure of the software, but exists to convey an overall view of the system. In UML, this is displayed through Use case diagrams; the dynamic aspect is represented in Interaction diagrams, Statechart diagrams, and Activity diagrams.

The Design view includes the classes, interfaces, and collaborations that form the vocabulary of the problem and its solution. This representation primarily supports the functional requirements for the system, the value of the services that the system must provide to the end user. In UML, this is displayed through class diagrams (Class diagram) and objects (Object diagram), the dynamic aspect is displayed in interaction, state, and activity diagrams.

Process view includes threads and processes that form parallel processing and synchronization in the system. This view primarily relates to system performance, scalability, and throughput. In UML, the static and dynamic aspects are represented by the same diagrams as in the Design view, but the focus is on active classes representing processes and threads.

The Implementation view includes the components and files used to build the system. This view primarily relates to configuration management of product releases. The static aspect in UML is represented by a component diagram, and the dynamic aspect by interaction, state, and activity diagrams.

The Deployment view includes the nodes and their interactions - they define the hardware topology on which the software runs. This view primarily relates to the distribution, delivery, and installation of the components that make up the physical system. The static aspect in UML is represented by a deployment diagram, and the dynamic aspect by interaction, state, and activity diagrams.

Below are definitions and examples of diagrams:

Class diagram a structural diagram that shows many classes, interfaces, collaborations and relationships between them (Fig. 7);

Object diagram a structure diagram that shows many objects and the relationships between them. It can be considered a special case of a class diagram. Modeling tools do not need to support a separate format for feature diagrams. They depict objects, so a class diagram that does not have classes, but has objects that belong to them, can be considered an object diagram;

Use case diagram behavior diagram, which shows many precedents and actors, as well as the relationships between them (Fig. 8);

Interaction diagram:

- Sequence diagram behavior diagram, which shows the interaction and emphasizes the time sequence of events (Fig. 9),

- Collaboration diagram behavior diagram, which shows the interaction and emphasizes the structural organization of objects sending and receiving messages (Fig. 10);

Statechart diagram behavior diagram, which shows the machine and emphasizes the behavior of objects in terms of the order in which events are received (Fig. 11);

Activity diagram behavior diagram, which shows the machine and highlights the transitions of control flow from one activity to another (Fig. 12);

Component diagram a diagram that shows the organization of a certain set of components and the dependencies between them, refers to the statistical view of the system (Fig. 13);

system topology diagram (Deployment diagram) structural diagram showing nodes and relationships between them (Fig. 14).

To be continued.