Modeling in UML. Implementation diagrams

        Unified Modeling Language (UML) is a language for specifying, visualizing, constructing and documenting software systems, as well as business models and other non-software systems. UML is a combination of engineering techniques that have previously been successfully used to model large and complex systems

        The creators of UML present it as a language for defining, representing, designing and documenting software systems, business systems and other systems of various natures. UML defines a notation and a metamodel. Notation is a collection of graphical objects that are used in models; it is the syntax of the modeling language.

        UML provides expressive tools for creating visual models that:

• are uniformly understood by all developers involved in the project;
• are a means of communication within the project.

        Unified Modeling Language (UML):

• does not depend on object-oriented (OO) programming languages;
• does not depend on the project development methodology used;
• can support any OO programming language.

        UML is open and has tools for extending the basic core. UML can be used to meaningfully describe classes, objects, and components in different subject areas, often very different from each other.

UML Diagrams

        Rational Rose provides the following types of diagrams at the disposal of the system designer, the sequential creation of which allows you to get a complete picture of the entire designed system and its individual components:

• Use case diagram;
• Deployment diagram (topology diagrams);
• Statechart diagram;
• Interaction diagram; Activity diagram;
• Sequence diagram;
• Collaboration diagram;
• Class diagram;
• Component diagram (component diagrams);
• Behavior diagrams;
• Activity diagram;
• Implementation diagrams;

        Each of these diagrams specifies different ideas about the system model. At the same time, the use case diagram represents a conceptual model of the system, which is the starting point for constructing all other diagrams. A class diagram is a logical model that reflects the static aspects of the structural design of a system, and behavior diagrams, which are also types of a logical model, reflect the dynamic aspects of its functioning. Implementation diagrams serve to represent the components of a system and refer to its physical model.

        Of the diagrams listed above, some serve to designate two or more subspecies. The following diagrams are used as independent representations: use cases, classes, states, activities, sequences, cooperation, components and deployment.

        For UML diagrams, there are three types of visual symbols that are important in terms of the information they contain:

• communications, which are represented by different lines on the plane;
• text, contained within the boundaries of individual geometric shapes;
• graphic symbols, depicted near the visual elements of the diagrams.

        When graphically depicting diagrams, it is recommended to adhere to the following rules:

• each diagram must be a complete representation of some fragment of the modeled subject area;
• the model entities presented on the diagram must be of the same conceptual level;
• all information about entities must be clearly presented on the diagram;
• diagrams should not contain conflicting information;
• diagrams should not be overloaded with text information;
• each diagram must be self-sufficient for the correct interpretation of all its elements;
• the number of diagram types required to describe a specific system is not strictly fixed and is determined by the developer;
• system models should contain only those elements that are defined in the UML notation.

Entities in UML

        There are four types of entities defined in UML: structural, behavioral, grouping and annotation. Entities are the main object-oriented elements of the language with which models are created.

        Structural entities are nouns in UML models. Typically, they represent static parts of the model, corresponding to conceptual or physical elements of the system. Examples of structural entities are "class", "interface", "collaboration", "use case", "component", "node", "actor".

        Behavioral Entities are dynamic components of the UML model. These are verbs that describe the behavior of the model in time and space. There are two main types of behavioral entities:

• interaction is behavior, the essence of which is the exchange of messages between objects within a specific context to achieve a specific goal;
• automaton - a behavioral algorithm that defines a sequence of states through which an object or interaction passes in response to various events.

        Grouping Entities are the organizing parts of the UML model. These are blocks into which the model can be decomposed. Such a primary entity exists in a single copy - this is a package.

        Packages are a universal mechanism for organizing elements into groups. Structural, behavioral, and other grouping entities can be placed in a package. Unlike components that actually exist while the program is running, packages are purely conceptual in nature, that is, they exist only during the development process.

        Annotation Entities- These are the explanatory parts of the UML model: comments for additional description, clarification or remarks on any element of the model. There is only one basic type of annotation element - a note. Notes are used to provide diagrams with comments or restrictions, expressed in informal or formal text.

Relationships in UML

        The following types of relationships are defined in the UML language: dependence, association, generalization and implementation. These relationships are the main connecting constructs of UML and are also used as entities to build models.

        Dependency- this is a semantic relationship between two entities, in which a change in one of them, independent, can affect the semantics of the other, dependent.

        Association- a structural relationship that describes a set of semantic or logical connections between objects.

        Generalization is a relationship in which a specialized element object (descendant) can be substituted for a generic element object (ancestor). At the same time, in accordance with the principles of object-oriented programming, a descendant (child) inherits the structure and behavior of its ancestor (parent).

        Realization is a semantic relationship between classifiers in which one classifier defines an obligation and the other guarantees its fulfillment. Implementation relationships occur in two cases:

• between interfaces and the classes or components that implement them;
• between precedents and the cooperations that implement them.

Common UML Mechanisms

        To accurately describe a system in UML, so-called general mechanisms are used:

• specifications;
• additions (adornments);
• common divisions;
• extensions (extensibility mechanisms).

        UML is not only a graphical language. Behind each graphic element there is its notation specification, containing a textual representation of the corresponding language construct. For example, an icon for a class has a specification that describes its attributes, operations, and behavior, although visually, in a diagram, the icon often reflects only a small part of this information. Moreover, the model may contain a different representation of this class, reflecting completely different aspects of it, but, nevertheless, consistent with the specification. Thus, UML graphical notation is used to visualize the system, and using specifications to describe its details.

        Almost every UML element has a unique graphical representation that gives a visual representation of its most important characteristics. The entity notation "class" contains its name, attributes and operations. The class specification may contain other details, such as the visibility of attributes and operations, comments, or an indication that the class is abstract. Many of these details can be visualized as graphics or text. additions to a standard rectangle that represents the class.

        When modeling object-oriented systems, there is a certain division represented entities.

        Firstly, there is a division into classes and objects. A class is an abstraction, and an object is a concrete embodiment of that abstraction. In this regard, almost all language constructs are characterized by class/object duality. Thus, there are precedents and instances of precedents, components and instances of components, nodes and instances of nodes. In a graphical representation, it is customary to use the same symbol for an object as for a class, and underline the name.

        Secondly, there is a division into an interface and its implementation. An interface declares commitments, and an implementation represents the concrete implementation of those commitments and ensures that the declared semantics are followed exactly. Because of this, almost all UML constructs are characterized by an interface/implementation duality. For example, precedents are implemented by collaborations, and operations are implemented by methods.

        UML is an open language, that is, it allows controlled extensions to reflect the features of domain models.

        UML extension mechanisms include:

• stereotypes (stereotype) - expand the UML vocabulary, allowing you to create new ones based on existing language elements, focused on solving a specific problem;
• tagged values ​​- extend the properties of basic UML constructs, allowing additional information to be included in the element specification;
• restrictions (constraints) - expand the semantics of UML constructs, allowing you to create new and cancel existing rules.

        Together, these three language extension mechanisms allow you to modify it in accordance with the needs of the project or the features of the development technology.

Use case diagram

        This type of diagram allows you to create a list of operations that the system performs. Often this type of diagram is called a function diagram, because based on a set of such diagrams, a list of requirements for the system is created and the set of functions performed by the system is determined.

Figure - 1. Use case diagram

        Use case diagrams describe the functionality of a system or what the system is supposed to do. The development of the diagram has the following goals:

• determine the general boundaries and context of the modeled subject area;
• formulate general requirements for the functional behavior of the designed system;
• develop an initial conceptual model of the system for its subsequent detailing in the form of logical and physical models;
• prepare initial documentation for the interaction of system developers with its customers and users.

        The essence of the use case diagram is as follows. The system being designed is represented as a set of entities or actors that interact with the system through use cases. In this case, an actor or actor is any entity that interacts with the system from the outside. This can be a person, a technical device, a program or any other system that can serve as a source of influence on the simulated system as determined by the developer himself. Use case serves to describe the services that the system provides to the actor.

        The purpose of a use case is to define a complete aspect or fragment of the behavior of some entity without revealing its internal structure. Such an entity can be a system or any element of the model that has its own behavior.

        Each use case corresponds to a separate service that the modeled entity provides at the request of the actor, that is, it determines how this entity will be used. A service that is initialized at the request of an actor is a complete, indivisible sequence of actions. This means that after the system has finished processing a request, it must return to its original state in order to be ready to process subsequent requests

        Use cases can be used both to specify external requirements for the system being designed, and to specify the functional behavior of an existing system. The set of use cases as a whole should define all possible aspects of the expected behavior of the system. In addition, use cases implicitly set requirements that define how actors must interact with the system in order to be able to correctly operate the services provided. For convenience, many use cases can be treated as a separate package.

        Examples of use cases may include the following actions: checking the status of the client's current account, placing an order for the purchase of goods, obtaining additional information about the client's creditworthiness, displaying a graphical form on the monitor screen and other actions.

class diagram

        The central place in object-oriented programming is the development of a logical model of the system in the form of a class diagram. A class diagram is used to represent the static structure of a system model in the terminology of object-oriented programming classes. A class diagram can reflect, in particular, various relationships between individual domain entities, such as objects and subsystems, as well as describe their internal structure and types of relationships.

Figure - 2. Class diagram

        Diagram icons allow you to display a complex hierarchy of systems, relationships between classes (Classes) and interfaces (Interfaces). This type of diagram is opposite in content to the Collaboration diagram, which displays system objects. Rational Rose allows you to create classes using this type of diagram in a variety of notations. similar to a cloud. Thus, a class is just a template according to which a specific object will be created in the future.

        A class diagram is a graph whose vertices are elements of the “classifier” type, connected by various types of structural relationships. A class diagram can also contain interfaces, packages, relationships, and even individual instances such as objects and relationships.

        Class in UML, it is used to denote a set of objects that have the same structure, behavior, and relationships with objects of other classes. Graphically, a class is depicted as a rectangle, which can additionally be divided by horizontal lines into sections or sections. These sections can include the class name, attributes (variables), and operations (methods).

statechart diagram

        Each state diagram in UML describes all possible states of one instance of a certain class and possible sequences of its transitions from one state to another, that is, it models all changes in the states of an object as its response to external influences.

        State diagrams are most often used to describe the behavior of individual objects, but can also be used to specify the functionality of other model components, such as use cases, actors, subsystems, operations, and methods.

Figure - 2. State diagram

        A state diagram is a special type of graph that represents a certain automaton. The vertices of the graph are the possible states of the machine, depicted by the corresponding graphic symbols, and the arcs indicate its transitions from state to state. State diagrams can be nested to provide a more detailed representation of individual model elements.

        In the UML metamodel machine is a package that defines many concepts necessary to represent the behavior of the modeled entity in the form of a discrete space with a finite number of states and transitions.

        The duration of the system being in any of the possible states significantly exceeds the time spent on transition from one state to another. It is assumed that in the limit the transition time can be equal to zero (unless otherwise otherwise specified), that is, the change in object states can occur instantly.

        The behavior of the automaton is modeled as sequential movement along the graph from vertex to vertex, taking into account the orientation of the arcs connecting them.

        The following mandatory conditions must be met for the machine:

• the state into which an object can go is determined only by its current state and does not depend on its previous history;
• At each moment of time, the automaton can be in only one of its states. At the same time, the automaton can remain in a separate state for as long as desired if no events occur;
• the time the machine is in one state or another, as well as the time it takes to achieve one state or another, are not specified in any way;
• the number of states of the automaton must be finite and all of them must be specified explicitly. Individual pseudo-states may not have specifications (initial and final states). In this case, their purpose and semantics are completely determined from the context of the model and the state diagram under consideration;
• The automaton graph should not contain isolated states and transitions. For each state, except the initial one, a previous state must be determined, and each transition must connect two states of the machine;
• the automaton should not contain conflicting transitions, when the object can simultaneously transition to two or more subsequent states (except for the case of parallel sub-automata). In UML, conflict elimination is possible by introducing guard conditions.

state is fundamental not only in the UML language metamodel, but also in applied systems analysis. The entire concept of a dynamic system is based on the concept of state. The semantics of state in the UML language has a number of specific features.

        In UML, a state is an abstract metaclass used to model a specific situation during which certain conditions are met. State can be specified as a set of specific class or object attribute values. Changes in individual attribute values ​​will reflect changes in the state of the class or object being modeled.

Activity diagram

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

        In fact, this type of diagram can also be used to reflect the states of the modeled object, however, the main purpose of the Activity diagram is to reflect the business processes of the object. This type of diagram allows you to show not only the sequence of processes, but also the branching and even synchronization of processes.

        This type of diagram allows you to design algorithms for the behavior of objects of any complexity, including can be used to draw up block diagrams.

        To model the process of performing operations in the UML language, activity diagrams are used. The graphical notation used in them is in many ways similar to the notation of a state diagram, since these diagrams also contain state and transition symbols. Each state in an activity diagram corresponds to the completion of some elementary operation, and the transition to the next state occurs only when this operation is completed.

        Thus, activity diagrams can be considered a special case of state diagrams. They allow you to implement in the UML language the features of procedural and synchronous control due to the completion of internal activities and actions. The main use of activity diagrams is to visualize the implementation features of class operations, when it is necessary to present algorithms for their implementation.

        In the context of the UML language activity is a set of individual calculations performed by an automaton, leading to some result or action. An activity diagram displays the logic and sequence of transitions from one activity to another, and focuses the analyst's attention on the results. The result of an activity may result in a change in the state of the system or the return of some value.

        Action state is a special case of a state with some input action and at least one transition leaving the state. This transition implicitly assumes that the input action has already completed. The action state cannot have internal transitions because it is elementary. A common use of an action state is to model one step in the execution of an algorithm (procedure) or control flow.

Sequence diagram

        When considering state and activity diagrams, it was noted that although these diagrams are used to specify the dynamics of system behavior, time is not explicitly present in them. The temporal aspect of behavior can be significant when modeling synchronous processes that describe the interactions of objects. To model the interaction of objects over time, UML uses sequence diagrams.

        Only those objects, which are directly involved in the interaction. The key to sequence diagrams is the dynamics of how objects interact over time.

        In UML, a sequence diagram has two dimensions. The first is from left to right in the form of vertical lines, each of which depicts the life line of a separate object participating in the interaction. The object on the far left of the diagram is the one that initiates the interaction. To the right is another object that directly interacts with the first. Thus, all objects in a sequence diagram form some order, determined by the order or degree of activity of objects when interacting with each other.

        Graphically, each object is depicted as a rectangle and is located in the upper part of its life line. Inside the rectangle, write the object name and the class name, separated by a colon. In this case, the entire record is emphasized, which is a sign of the object.

        The second dimension of a sequence diagram is the vertical time axis, directed from top to bottom. The topmost part of the diagram corresponds to the initial moment of time. Object interactions are implemented through messages sent by one object to another. Messages are depicted as horizontal arrows with the message name, and their order is determined by the time of occurrence. That is, messages located higher in the sequence diagram are initiated before those located lower. The scale on the time axis is not indicated, since the sequence diagram models only the temporal ordering of “earlier-later” interactions.

Collaboration diagram

        The main feature of a cooperation diagram is the ability to graphically represent not only the sequence of interaction, but also all the structural relationships between the objects participating in this interaction.

Figure - 3. Cooperation diagram

        This type of diagram allows you to describe the interactions of objects, abstracting from the sequence of message transmission. This type of diagram shows in a compact form all received and transmitted messages of a particular object and the types of these messages.

        First of all, the cooperation diagram depicts the objects participating in the interaction in the form of rectangles, containing the name of the object, its class and, possibly, attribute values. Further, as in the class diagram, associations between objects are indicated in the form of various connecting lines. In this case, you can explicitly specify the names of the association and the roles that objects play in this association. Additionally, dynamic connections - message flows - can be depicted. They are also represented as connecting lines between objects, above which there is an arrow indicating the direction, message name and sequence number in the general sequence of message initialization.

        Unlike a sequence diagram, a cooperation diagram depicts only the relationships between objects that play specific roles in the interaction. This chart does not show time as a separate dimension. Therefore, the sequence of interactions and parallel flows can be determined using sequence numbers. Therefore, if you need to explicitly specify the relationships between objects in real time, it is better to do this in a sequence diagram.

        Concept cooperation is one of the fundamental concepts in the UML language. It serves to designate a set of objects interacting with a specific purpose in the general context of the modeled system. The purpose of the cooperation itself is to specify the implementation features of the individual most significant operations in the system. Cooperation defines the structure of system behavior in terms of the interaction of participants in this cooperation.

        Cooperation can be represented at two levels:

• specification level - shows the roles of classifiers and the roles of associations in the interaction under consideration;
• example level - indicates instances and relationships that form individual roles in cooperation.

        A specification level cooperation diagram shows the roles played by the elements involved in the interaction. The elements of cooperation at this level are classes and associations, which denote the individual roles of classifiers and associations between participants in the cooperation.

        The example-level cooperation diagram is represented by a set of objects (instances of classes) and connections (instances of associations). In this case, the connections are supplemented with message arrows. At this level, only objects that are directly related to the implementation of the operation or classifier are shown. In this case, it is not at all necessary to depict all properties or all associations, since the cooperation diagram contains only the roles of classifiers, but not the classifiers themselves. Thus, while a classifier requires a complete description of all its instances, the role of a classifier requires the description of only those properties and associations that are necessary to participate in a particular cooperation.

        An important consequence follows from this. The same set of objects can participate in different cooperations. Depending on the cooperation under consideration, both the properties of individual objects and the connections between them can change. This is what distinguishes a collaboration diagram from a class diagram, which must indicate all the properties and associations between the elements of the diagram.

Component diagram

        This type of diagram is intended to distribute classes and objects among components during the physical design of a system. This type of diagram is often called module diagrams.

Figure - 4. Component diagram

        A complete software system design is a set of models of logical and physical levels that must be consistent with each other. UML uses implementation diagrams to physically represent system models, which include component diagram And deployment diagram.

        A component diagram, unlike the previously discussed diagrams, describes the features of the physical representation of the system. It allows you to determine the architecture of the system being developed by establishing dependencies between software components, which can be source and executable code. The main graphical elements of a component diagram are components, interfaces, and dependencies between them.

        The component diagram is developed for the following purposes:

• visualization of the general structure of the source code of the software system;
• specifications of the executable version of the software system;
• ensuring reuse of individual program code fragments;
• representations of conceptual and physical database schemas.

        Both system analysts and architects, as well as programmers, participate in the development of component diagrams. A component diagram provides a consistent transition from a logical representation to a concrete implementation of a project in the form of software code. Some components can exist only at the stage of compilation of the program code, others at the stage of its execution. A component diagram reflects the general dependencies between components, treating the latter as classifiers.

        To represent physical entities in the UML language, a special term is used - component. The component implements a certain set of interfaces and serves to generally designate the elements of the physical representation of the model. To graphically represent a component, a special symbol is used - a rectangle with two smaller rectangles inserted on the left. Inside the large rectangle is the name of the component and, if necessary, some additional information. The appearance of this symbol may vary slightly depending on the nature of the information associated with the component.

Deployment diagram

        This type of diagram is intended for analyzing the hardware of the system, that is, hardware, not programs. Directly translated from English, Deployment means “deployment,” but the term “topology” more accurately reflects the essence of this type of diagram.

Figure - 5. Deployment diagram

        The physical representation of a software system cannot be complete if there is no information on what platform and on what computing means it is implemented. If a program is being developed that runs locally on the user's computer and does not use peripheral devices and resources, then there is no need to develop additional diagrams. When developing corporate applications, the presence of such diagrams can be extremely useful for solving problems of rational placement of components in order to effectively use distributed computing and communication resources of the network, ensuring security, and others.

        Deployment diagrams are used to represent the general configuration and topology of a distributed software system in UML.

        The deployment diagram is designed to visualize the elements and components of a program that exist only at the runtime stage. In this case, only program instance components, which are executable files or dynamic libraries, are represented. Those components that are not used at runtime are not shown in the deployment diagram. Thus, components with program source codes can only be present on the component diagram. They are not indicated on the deployment diagram.

        The deployment diagram contains graphical representations of processors, devices, processes and connections between them. Unlike logical representation diagrams, a deployment diagram is uniform for the system as a whole, since it must fully reflect the features of its implementation. Developing a deployment diagram is typically the last step in specifying a software system model.

        When developing a deployment diagram, the following goals are pursued:

• determine the distribution of system components across its physical nodes;
• show physical connections between all nodes of the system implementation at the stage of its execution;
• identify system bottlenecks and reconfigure its topology to achieve the required performance.

        Deployment diagrams are developed jointly by system analysts, network engineers and systems technicians.

Features of the Rational Rose work interface

        The Rational Rose CASE tool implements generally accepted standards for the program's operating interface, similar to well-known visual programming environments. After installing Rational Rose on the user's computer, which causes virtually no difficulties even for beginners, launching this program in MS Windows 95/98 leads to the appearance of a working interface on the screen (Fig. 6).

Figure - 6. General view of the working interface of the Rational Rose program

        The Rational Rose operating interface consists of various elements, the main ones being:

• Main menu of the program
• Diagram window
• Documentation Window
• Browser window
• Log window

Let us briefly consider the purpose and main functions of each of these elements.

Main menu of the program

The main menu of the program is made in the generally accepted standard and looks like this (Fig. 7).

Individual menu items, the purpose of which is clear from their names, combine similar operations related to the entire project as a whole. Some of the menu items contain well-known functions (opening a project, printing diagrams, copying to and pasting various diagram elements from the clipboard). Others are so specific that they may require additional effort to study (code generation options, checking model consistency, connecting additional modules).

Figure - 7. Appearance of the main menu of the program

Standard toolbar

The standard toolbar is located below the main menu of the program and looks like this (Fig. 8). Some of the tools are not available (the new project does not have any elements). The standard toolbar provides quick access to the menu commands that developers use most frequently.

Figure - 8. Appearance of the standard toolbar

The user can customize the appearance of this panel at his own discretion. To do this, select the menu item Tools -> Options and open the Toolbars tab. This way you can show or hide various tool buttons and change their size.

Browser window

The default browser window is located on the left side of the working interface under the standard toolbar (Fig. 9).

The browser organizes model views in a hierarchical structure that simplifies navigation and allows you to find any model element in the project. In this case, any element that the developer adds to the model is immediately displayed in the browser window. Accordingly, by selecting an element in the browser window, we can visualize it in the diagram window or change its specification. The browser also allows you to organize model elements into packages and move elements between different views of the model. If desired, the browser window can be located in another place in the working interface or hidden altogether using the View menu item. You can also resize the browser by dragging its outer frame with your mouse.

Figure - 9. Browser appearance

Special toolbar

A special toolbar is located between the browser window and the chart window in the middle part of the working interface. By default, a toolbar is offered for constructing a model class diagram (Fig. 10).

Figure - 10. Appearance of a special toolbar for a class diagram

The location of the special toolbar can be changed by moving the panel frame to the desired location. You can also customize the composition of the panel by adding or removing individual buttons corresponding to certain tools. Button assignments can be learned from tooltips that appear after the mouse pointer hovers over the corresponding button.

Diagram window

The diagram window is the main work area of ​​its interface, in which various views of the project model are visualized. By default, the diagram window is located on the right side of the working interface, but its location and size can also be changed. When developing a new project, if the Project Wizard has not been used, the diagram window is a blank area that does not contain any model elements (Fig. 11).

The name of the diagram that is located in this window is indicated in the title bar of the program (the topmost line of the program) or, if the window is not maximized to full screen, in the title bar of the chart window. Several charts can be present in the chart window at the same time, but only one of them can be active. For example, in Fig. 11 the active diagram is the deployment diagram, although there are other diagrams. Switching between diagrams can be done by selecting the desired view on the standard toolbar or through the Window menu item. When you activate a separate chart view, the appearance of a special toolbar changes, which is customized for the specific chart view.

Figure - 11. Appearance of the diagram window with different types of model views

Documentation Window

The documentation window may not be present on the screen by default. In this case, it can be activated through the menu item View -> Documentation, after which it will appear below the browser (Fig. 12).

The documentation window, as its name suggests, is designed to document the elements of a model view. You can record a wide variety of information in it, and what is important - in Russian. This information is subsequently converted into comments and does not in any way affect the execution logic of the program code.

In the documentation window, the information that relates to the individual selected element of the diagram is activated. In this case, you can select an element either in the browser window or in the diagram window. When you add a new element to the diagram (for example, a class), documentation for it is automatically generated, which is empty (No documentation). Subsequently, the developer independently enters the necessary explanatory information, which is remembered and can be changed during the work on the project.

Just like for other windows of the working interface, you can change the size and position of the documentation window.

Figure - 12. Appearance of the documentation window

Log window

The Log window is designed to automatically record various service information generated while working with the program. The log records the time and nature of actions performed by the developer, such as updating the model, customizing menus and toolbars, as well as error messages that occur when generating program code.

The log window is always present on the working interface in the diagram window area (Fig. 13). However, it may be hidden by other chart windows or minimized. You can activate the log window through the Window->Log menu. In this case, it is displayed on top of other windows in the right area of ​​the working interface. This window cannot be completely removed, it can only be minimized.

Figure - 13. Log window appearance

Conclusion

        Over time, the UML language will become the “Esperanto” in which mathematicians, systems analysts, physicists, programmers, managers, economists and specialists of other professions will be able to communicate, presenting their professional knowledge in a unified form. After all, in essence, each of the specialists operates with model representations in their field of knowledge. And it is precisely this model aspect that can be specified using the UML language.

        In this regard, the importance of the UML language is increasing significantly, since it is increasingly acquiring the features of a knowledge representation language. At the same time, the presence in the UML language of visual means for representing the structure and behavior of the model makes it possible to achieve an adequate representation of declarative and procedural knowledge and, no less important, to establish semantic correspondence between these forms of knowledge. All these features of the UML language allow us to conclude that it has the most serious prospects in the near future.

This article explores the new era of software development, how it impacts new UML requirements, and best practices for meeting them.
  7. “Data modeling in Rational Rose” Sergey Trofimov Describes the modeling of the physical representation of data using Rational Rose
  8. UML language. General understanding of the UML language: structures, graphical elements and diagrams of the language.
  9. Practical UML. This document is a translation of the document "Practical UML. A Hands-On Introduction for Developers". Practical introduction for developers
  10. "Standard object-oriented modeling language UML" Vendrov Alexander Mikhailovich. History of UML
  11. UML – unified modeling language. This material contains initial information about methods for describing software systems and notations used in UML
  12. UML language. User guide. Authors: Grady Booch, James Rumbaugh, Ivar Jacobson
  13. "UML diagrams in Rational Rose" Sergey Trofimov
  14. "Analysis and design. Visual modeling (UML) Rational Rose" Konstantin Domolego
  15. Library of Gennady Vernikov. Complete descriptions of design and modeling standards.
  16. “An example of describing a subject area using UML when developing software systems” E.B. Zolotukhina, R.V. Alfimov. The article uses a specific example to demonstrate a possible approach to domain modeling based on the use of the Unified Modeling Language (UML)

       

Today, the process of creating complex software applications cannot be imagined without dividing it into life cycle stages. By the life cycle of a program we mean a set of stages:

• Analysis of the subject area and creation of technical specifications (interaction with the customer)
• Designing the program structure
• Coding (set of program code according to project documentation)
• Testing and Debugging
• Implementation of the program
• Program support
• Disposal

Let's take a closer look at the design process. During the design process, an architect or an experienced programmer creates design documentation, including text descriptions, diagrams, and models of the future program. The UML language will help us in this difficult task.

UML is a graphical language for visualization, description of parameters, design and documentation of various systems (programs in particular). Diagrams are created using special CASE tools, such as Rational Rose (http://www-01.ibm.com/software/rational/) and Enterprise Architect (http://www.sparxsystems.com.au/). A unified information model is built based on UML technology. The above CASE tools are capable of generating code in various object-oriented languages, and also have a very useful reverse engineering function. (Reverse engineering allows you to create a graphical model from existing program code and comments to it.)

Let's look at the types of diagrams for visualizing the model (this is a must have, although there are many more types):

Use case diagram

The designed system is represented as a set of entities or actors interacting with the system using so-called precedents. In this case, an actor or actor is any entity that interacts with the system from the outside. In other words, each use case defines a certain set of actions performed by the system during a dialogue with the actor. However, nothing is said about how the interaction of actors with the system will be implemented.

class diagram

A class diagram serves to represent the static structure of a system model in the terminology of object-oriented programming classes. A class diagram can reflect, in particular, the various relationships between individual domain entities, such as objects and subsystems, and also describes their internal structure (fields, methods...) and types of relationships (inheritance, implementation of interfaces...). This diagram does not provide information about the timing aspects of system operation. From this point of view, the class diagram is a further development of the conceptual model of the designed system. At this stage, knowledge of the OOP approach and design patterns is essential.

statechart diagram

The main purpose of this diagram is to describe possible sequences of states and transitions that together characterize the behavior of a model element during its life cycle. A state diagram represents the dynamic behavior of entities based on the specification of their response to the perception of some specific events.

Sequence diagram

To model the interaction of objects in the UML language, appropriate interaction diagrams are used. The interactions of objects can be viewed in time, and then a sequence diagram is used to represent the timing of the transmission and reception of messages between objects. Interacting objects exchange some information with each other. In this case, the information takes the form of completed messages. In other words, although the message has informational content, it acquires the additional property of exerting a directed influence on its recipient.

Collaboration diagram

In the cooperation diagram, the objects participating in the interaction are depicted in the form of rectangles, containing the name of the object, its class and, possibly, attribute values. Like a class diagram, associations between objects are indicated in the form of various connecting lines. In this case, you can explicitly specify the names of the association and the roles that objects play in this association.
Unlike a sequence diagram, a cooperation diagram depicts only the relationships between objects that play specific roles in the interaction.

Component diagram

A component diagram, unlike the previously discussed diagrams, describes the features of the physical representation of the system. A component diagram allows you to define the architecture of the system being developed by establishing dependencies between software components, which can be source, binary and executable code. In many development environments, a module or component corresponds to a file. The dotted arrows connecting modules show interdependence relationships similar to those that occur when compiling program source code. The main graphical elements of a component diagram are components, interfaces, and dependencies between them.

Deployment diagram

The deployment diagram is designed to visualize the elements and components of a program that exist only at the runtime stage. In this case, only program instance components, which are executable files or dynamic libraries, are represented. Those components that are not used at runtime are not shown in the deployment diagram.
A deployment diagram contains graphical representations of processors, devices, processes, and the connections between them. Unlike logical representation diagrams, a deployment diagram is uniform for the system as a whole, since it must fully reflect the features of its implementation. This diagram essentially completes the OOAP process for a particular software system and its development is usually the last stage of model specification.

This concludes our overview of diagrams in particular and design in general. It is worth noting that the design process has long become a standard for software development, but often you have to deal with a superbly written program, which, due to the lack of normal documentation, becomes overgrown with unnecessary side functionality, crutches, becomes cumbersome and loses its former quality. =(

I am convinced that a programmer is first and foremost a coder - he should NOT communicate with the customer, should NOT think about the architecture of the system, should not invent an interface to the program, he should only code - implement algorithms, functionality, appearance, usability, but nothing more …. The designer must, starting from abstract diagrams (describing the subject area) to diagrams representing the structure of data, classes and processes of their interaction, describe everything in detail step by step. That is, the complexity of the work and the salary of a designer should be an order of magnitude higher than that of a programmer == coder. Sorry for the sedition....

A complete software system design is a set of logical and physical level models that must be consistent with each other. UML uses implementation diagrams to physically represent system models, which include a component diagram and a deployment diagram.

A component diagram, unlike the previously discussed diagrams, describes the features of the physical representation of the system. It allows you to determine the architecture of the system being developed by establishing dependencies between software components, which can be source and executable code. The main graphical elements of a component diagram are components, interfaces, and dependencies between them.

A component diagram is developed for the following purposes:

visualization of the general structure of the source code of the software system;

specifications of the executable version of the software system;

ensuring reuse of individual program code fragments;

representations of conceptual and physical database schemas.

The development of component diagrams involves both system analysts and architects, as well as programmers. A component diagram provides a consistent transition from a logical representation to a concrete implementation of a project in the form of software code. Some components can exist only at the stage of compilation of the program code, others at the stage of its execution. A component diagram reflects the general dependencies between components, treating the latter as classifiers.

Components

To represent physical entities in the UML language, a special term is used - component. The component implements a certain set of interfaces and serves to generally designate the elements of the physical representation of the model. To graphically represent a component, a special symbol is used - a rectangle with two smaller rectangles inserted on the left. Inside the large rectangle is the name of the component and, if necessary, some additional information. The appearance of this symbol may vary slightly depending on the nature of the information associated with the component.

The component name follows the general rules for naming model elements in the UML language and can consist of any number of letters, numbers, and some punctuation marks.

An individual component can be represented at the type level or at the instance level. The graphical representation is the same in both cases, but the rules for writing the component name are different. If a component is represented at the type level, then only the capitalized type name is written as its name. If the component is represented at the instance level, then its name is written<имя компонента>":"<имя типаХ>. In this case, the entire name line is underlined.

As simple names, it is customary to use the names of executable files (indicating the exe extension after the separator dot), dynamic libraries (dll extension), Web pages (html extension), text files (txt or doc extension) or help files (hip), database files (DB) or files with program source codes (h, cpp extensions for the C++ language, java extension for the Java language), scripts (pi, asp) and others.

Since the specific implementation of the logical representation of the system model depends on the software tools used, the names of the components are determined by the syntax features of the corresponding programming language.

In some cases, information about the name of the enclosing package and the specific version of the implementation of this component can be added to the simple name of the component. In this case, the version number is written as a tagged value in curly braces. In other cases, a component symbol may be divided into sections to explicitly indicate the names of the interfaces it implements.

Since a component, as an element of the physical implementation of a model, represents a separate code module, it is sometimes commented on with additional graphic symbols illustrating the specific features of its implementation. These additional annotations are not specified in the UML, but their use makes the component diagram easier to understand by improving the clarity of the physical representation.

There are three types of components in UML:

deployments that enable the system to directly perform its functions. Such components can be dynamic link libraries with a dll extension, Web pages in hypertext markup language with an html extension, and help files with an hlp extension;

work products. As a rule, these are files with the source code of programs, for example, with the h or cpp extensions for the C++ language;

executions, which are executable modules - files with the exe extension.

These elements are sometimes called artifacts, emphasizing their complete information content, which depends on the specific technology for implementing the corresponding components.

Another way to specify different kinds of components is to explicitly indicate its component stereotype before the name. The UML defines the following stereotypes for components:

library - defines the first type of component, which is presented in the form of a dynamic or static library;

table - also defines the first type of component, which is represented in the form of a database table;

file (file) - defines the second type of component, which is presented in the form of files with the source code of programs;

document - defines the second type of component, . which is presented in the form of a document;

executable - defines the third type of component that can be executed in the node.

Interfaces

The next element of the component diagram is interfaces. In general, the interface is graphically represented by a circle that is connected to the component by a line segment without arrows. The interface name must begin with a capital letter "I" and be written next to a circle. Semantically, a line means an implementation of an interface, and the presence of interfaces on a component means that this component implements the corresponding set of interfaces.

Another way to represent an interface in a component diagram is to depict it as a class rectangle with an "interface" stereotype and possible attribute and operation sections. Typically, this notation is used to represent the internal structure of an interface, which may be important to the implementation.

When developing software systems, interfaces provide not only compatibility between different versions, but also the ability to make significant changes to some parts of the program without changing other parts. Thus, the purpose of interfaces is much broader than the specification of interaction with system users (actors).

Dependencies

In general, the dependence relation was also discussed earlier. Let us recall that dependence is not an association, but serves to represent only the fact of the existence of such a connection, when a change in one element of the model affects or leads to a change in another element of the model. A dependency relationship in a component diagram is represented by a dotted line with an arrow pointing from the client (the dependent element) to the source (the independent element).

Dependencies can reflect the connections between program modules at the stage of compilation and object code generation. Alternatively, the dependency may reflect the presence in the independent component of class definitions that are used in the dependent component to create the corresponding objects. When applied to a component diagram, dependencies can link components and the interfaces imported by that component, as well as different types of components to each other.

In the first case, an arrow is drawn from the client component to the imported interface. The presence of an arrow means that the component does not implement the corresponding interface, but uses it during its execution. Moreover, the same diagram may contain another component that implements this interface.

Another instance of a dependency relationship in a component diagram is the relationship between different kinds of components. The presence of such a dependency means that making changes to the source code of programs or dynamic libraries leads to changes to the component itself. In this case, the nature of the changes can be noted additionally.

A component diagram can also represent dependency relationships between components and the classes they implement. This information is important to ensure consistency between the logical and physical representations of the system model. If you want to emphasize that a component implements separate classes, then the extended rectangle symbol is used to denote the component. In this case, the component rectangle is divided into two sections by a horizontal line. The top section is used to record the component name, and the bottom section is used to indicate additional information.

Other elements of graphical notation, such as classes (type-level component) or objects (instance-level component), can be depicted within a component symbol. In this case, the component symbol is drawn to accommodate these additional symbols.

Objects that reside in a separate instance component are depicted as nested within that component's symbol. Such nesting means that the execution of a component entails the execution of the corresponding objects.

Developing a component diagram involves using information about both the logical representation of the system model and the features of its physical implementation. Before development begins, it is necessary to make decisions about the choice of computing platforms and operating systems on which the system is supposed to be implemented, as well as the choice of specific databases and programming languages.

After this, you can proceed to the general structuring of the component diagram. First of all, it is necessary to decide what physical parts (files) the software system will consist of. At this stage, attention should be paid to an implementation of the system that would provide not only the possibility of reusing code through rational decomposition of components, but also the creation of objects only when they are needed.

The point is that the overall performance of a software system significantly depends on the rational use of computing resources. For this purpose, it is necessary to move most of the descriptions of classes, their operations and methods into dynamic libraries, leaving in the executable components only the most necessary fragments of program code for initializing the program.

After the general structuring of the physical representation of the system, it is necessary to supplement the model with interfaces and database schemas. When developing interfaces, you should pay attention to the coordination (joining) of various parts of the software system. Including a database schema in a model involves specifying individual tables and establishing information relationships between tables.

The final stage of constructing a component diagram is associated with establishing and plotting mutual connections between components, as well as implementation relationships, on the diagram. These relationships should illustrate all the most important aspects of the physical implementation of the system, starting with the features of compilation of source codes of programs and ending with the execution of individual parts of the program at the stage of its execution. For this purpose, you can use various types of graphical representation of components.

When developing a component diagram, you should adhere to the general principles of creating models in the UML language. In particular, it is necessary to use components and stereotypes already available in the UML language. For most typical projects, this set of elements may be sufficient to represent the components and the dependencies between them.

If the project contains some physical elements that are not described in the UML language, then you should use the extension mechanism and use additional stereotypes for individual non-typical components or labeled values ​​to clarify their individual characteristics.

It should be noted that a component diagram is usually developed in conjunction with a deployment diagram, which provides information about the physical placement of software system components across its individual nodes.

A component diagram shows the parts of a software system design. A component diagram helps visualize the high-level structure of a system and the behavior of the services provided and consumed by these elements through interfaces. To create a UML component diagram, on the Architecture menu, click Create Diagram.

A component diagram can be used to describe a system design implemented in any language or style. It is only necessary to identify the parts of the structure that interact with other parts through a limited set of input and output channels. You can use components of any scale, interconnected in any way.

The following table describes the elements that can be used in a component diagram and their basic properties.

Figure	Element	Description and main properties
	Component	A reusable functional element of a system. A component exposes and consumes behavior through interfaces and can use other components. You can hide or show the internal parts of a component using the expand/collapse control (9). A component is a kind of class. Is an implicitly created instance. If true (the default), the component exists only as a design artifact. At runtime, only part of it exists.
	Provided interface port	Represents a group of messages or calls implemented by a component and available for use by other components or external systems. A port is a component property that has an interface as its type.
	Required interface port	Represents a group of messages or calls sent by a component to other components or external systems. The component is designed to connect to components that provide at least these operations. A port has an interface as its type.
	Addiction	Can be used to indicate that the required interface of one component can match the provided interface of another component. Dependencies can also be used more generally when working with model elements to show that the design of one depends on the design of another.
		An attribute of a component whose type is typically another component. The part is used in the internal design of its parent component. Graphically, parts are shown as nested within a parent component. To create part of an existing component type, drag the component from UML Model Explorer onto the owning component. To create a new type of part, select the Component tool and click the owning component. For example, the Car component has parts engine:CarEngine, backLeft:Wheel, frontRight:Wheel, etc. Multiple parts can be of the same type, and different components can have parts of the same type. Type. A part type defined elsewhere in the model. Typically the type is another component. Multiplicity. The default value is 1. You can set it to 0..1 to indicate that the part can be null, or you can set it to * to indicate that the part is a collection of instances of that type. You can also set the value to any expression that can be evaluated in a numeric range.
	Assembly part	A connection between the required interface ports of one part and the provided interface ports of another. The implementation of part assembly may vary for different components. Connected parts must have the same parent component.
	Delegation	Associates a port with an interface of one of the component parts. Indicates that messages sent to a component are processed by this part, or that messages sent by this part are sent from a parent component.
(not shown)	Generalization	Indicates that one component inherits from another. Parts and interfaces are inherited.
	Expand/collapse control	Allows you to hide or show the internal parts of a component.
(not shown)

This section is devoted to two diagrams at once: components and placement, for which you can use the general name ‒ implementation diagrams. This is due to the fact that these diagrams become especially important in the later phases of development - in the implementation and delivery phases. While in the early phases of development - analysis and design - these diagrams are either not used at all or have a very general, not detailed appearance.

From an implementation point of view, the designed system consists of components (represented in component diagrams) distributed across computing nodes (represented in placement diagrams).

In UML 2, compared to UML 1, there was a significant change, namely, the concept of "component" was divided into two components: logical and physical. Logical component that continues to bear the name component(component), is an element of the logical model of the system, while the physical component, called artifact(artifact), personifies the physical element of the designed system, located on computing node(node).

Component and layout diagrams have a lot in common, bringing together the following, closely related things:

• structure of logical elements (components);
• mapping logical elements (components) to physical elements (artifacts);
• the structure of the resources used (nodes) with physical elements (artifacts) distributed across them.

In this section we will deviate from the rule we adopted when describing the remaining diagrams. Namely, we will not consider separately for each diagram the entities used on it. It seems more correct to us to jointly consider all entities and relationships in one section, which is what we will do.

3.4.1. Interface

∇ Translation options found in the literature: “implemented”, “provided”.

∇∇ The translation option found in the literature is “requested”

However, we must not forget that the interface itself is simply a description of the contract, and it becomes provided or required depending on how this interface is used:

• if a classifier implements an interface, then for this classifier it is secured interface and this fact is shown using the implementation relation 3;
• if the classifier calls interface operations, then for this classifier it is required interface and this fact is shown using the dependency relationship 4.

Having dealt with interfaces, let's move on to components.

3.4.2. Components, Artifacts and Assemblies

Component(component) is a modular fragment of the logical representation of the system, interaction with which is described by a set of provided and required interfaces.

The concept of "component" is often associated with component or assembly programming, but for UML this correspondence is not legitimate. A UML component is part of a model, and describes a logical entity that exists only in design time(design time), although in the future it can be associated with a physical implementation (artifact) execution time(run time).

The UML standard provides stereotypes for components, as shown in the following table.

Table Standard Component Stereotypes

The analogue of a component in the sense of assembly programming is the concept of an artifact in UML. And not just any artifact, but only some of its stereotypes.

Artifact‒ is any artificially created element of a software system.

Elements of a software system, and therefore artifacts, can include executable files, program source code, web pages, help files, supporting documents, data files, models, and many other physical elements of information. In other words, artifacts are those information elements that are used in one way or another during the operation of a software system and are included in its composition.

In order to somehow reflect such a variety of artifact types, UML provides standard stereotypes listed in the table

Table Standard Artifact Stereotypes

However, real artifacts are much more diverse in their types than those listed above. To take this into account, many tools, in addition to standard stereotypes, support additional artifact stereotypes, often with special icons and shapes that make diagrams highly visible.

The most important aspect of using the concept of artifact in UML is that an artifact can participate in a manifestation relationship.

Manifestation‒ this is a dependency relationship with the “manifest” stereotype that links a model element (for example, a class or component) and its physical implementation in the form of an artifact.

Below is the class Company , which has a manifestation relationship (dependency with the stereotype "manifest") with two artifacts with the stereotype "source", which in turn define a runtime artifact, a dynamic library (with the stereotype "library") Company .

Generally speaking, a manifestation relationship is a many-to-many relationship; one model element can be implemented by many artifacts, and one artifact can participate in the implementation of many model elements.

Manifestation is graphically depicted by a relationship of dependence with the stereotype “manifest” from an artifact to a realized entity. Because manifestation is a many-to-many relationship, multiple dependency relationships in the model may be required to fully describe the manifestation relationship.

The third entity discussed in this section is a node.

∇ When using UML in other subject areas, a node can be not only a computer, but also another object: a person, a mechanical device, etc.

UML provides two stereotypes for "executionEnvironment" and "device" nodes.

A node with the “executionEnvironment” stereotype allows you to model the hardware and software platform on which the application is executed. Examples of runtime environments are: operating system, database management system, etc.

A node with the “device” stereotype also models a hardware and software platform, but allows the possibility of nesting one node within another, as shown in the following figure.

Artifacts of the system during its operation are placed on nodes, which is graphically expressed either by listing them inside node 1 (see figure above), or by a dependency relationship with the stereotype “deploy” between the artifact and node 1 (see figure below), or by depicting the artifact inside images of node 2 (see picture below). All notation options are equal.

If environment-specific parameters play an important role when placing an artifact on a node, then they can be specified using deployment specifications(deployment specification).

The deployment specification is depicted like a classifier (as a rectangle), but with the stereotype “deploymentSpec” and is associated with a dependency relationship with the artifact.

The last thing we need to consider in this section is the relationship associations between nodes.

If nodes are connected by an association relationship, then this means the same thing as in other contexts: the ability to exchange messages. In relation to computer networks consisting of nodes, association means the presence of a communication channel. If you need to specify additional information about the properties of a channel, this can be done using common mechanisms: stereotypes (for example, “tcp/ip”, see the figure below), restrictions and named values.

This is where we will end this overview paragraph, so that in the next we will get acquainted in more detail with diagrams of components and placement using the example of an information system for the personnel department.

3.4.3. Applying Component and Layout Diagrams

Let's try to answer the question of what interfaces, components and artifacts can be identified in the HR information system, as well as how it is advisable to place the developed software on computing nodes.

The main purpose of the designed information system is to store personnel data and perform certain operations with this data at the user’s direction. Analyzing the composition of operations, we see that they come down to the creation, modification and deletion of stored data elements. The standard solution in such situations is to use a ready-made DBMS (DBMS - Data Base Management System). From the point of view of designing an information system for the HR department, it is advisable to consider the DBMS used as a ready-made component with predefined interfaces and an interaction protocol. We don’t have to focus on the structure of this component - it is standard and, probably, quite well described outside of our model.

The DBMS will take over all functions for direct data manipulation: creating, deleting and searching for records in tables, etc. The implementation of the operations of our HR information system comes down to a certain sequence of elementary operations with data. For example, transferring an employee from one position to another would likely require changes to three data elements: the employee data and the old and new job data. However, is it advisable to consider that the definition and execution of the very sequence of elementary operations with data is also the prerogative of the component we have selected - the DBMS? Common practice answers this question in the negative. For many reasons it is better to separate this into a separate component, usually called business logic ∇. In addition, we must assume that our system must have a component responsible for the user interface. As a first approximation, we arrive at the component structure below, which is called a “three-tier architecture.”

∇ An extremely unfortunate, but often used term, which is a copy of the English business logic. Business logic has nothing to do with either business (in the Russian sense of the word) or logic. It would be more correct to use the complex phrase “data processing rules,” but we are afraid of being misunderstood.

UML 2 introduced the following changes to component diagram notation.

Firstly, components, like any classifier, can be depicted uniformly, in the form of rectangles, in which either the stereotype “component” 1 or one of the clarifying stereotypes given in table is indicated. Standard component stereotypes in paragraph 3.4.2 2, or the corresponding icon in the upper right corner of the rectangle 3.

Second, the required and provided interfaces can be represented using lollipop notation 4 (see Section 3.3.1), so that the relationship between components through some interface appears natural and symmetrical.

This is illustrated by the figure below, which shows the same entities and relationships as in the figure above.

The given example of a component diagram is quite trivial and does not look very convincing from the point of view of usefulness in architectural design. Recognizing this shortcoming, we will give another example related to the HR information system, in which we will try to show that component diagrams are a fairly expressive tool for architectural design.

Let us assume that in the projected information system of the HR department it is necessary to differentiate the rights to perform operations and access to data for different categories of users. Although our technical specifications do not say a word about this, for modern systems this requirement has become commonplace (sometimes clearly unnecessary), so the example is not far-fetched. We know many ways to implement differentiation of access rights to data, and there are probably even more ways unknown to us. We will not go into their description and discussion, but will limit ourselves to one thing - very simple, but effective. Our application has two actors (see paragraph 2.2.1), i.e. two categories of users. Let’s assume that it is enough to differentiate rights at the level of user categories. Then you can do the following: just make two different applications (or, as they usually say in such cases, two automated workstations- ARMA). Users who have access to the workstation as a whole can perform all operations of the workstation and, thus, have those and only those rights to access data that are provided by the operations implemented in the workstation.

For an application such as an HR information system, such a solution is practically sufficient. Thus, the differentiation of access rights to data is transferred to the level of access to computers and applications installed on them, and these are already problems of operating systems and enterprise security services, which can not be taken care of in the HR information system.

The decision made is easily expressed in a component diagram.

All that remains to be done is to determine the composition of the components, i.e. show which classes are included in which components.

The simplest way to show the relationship between a component and its member classes is to use the implementation relation 1, as shown below.

Another way to determine the composition of a component is to treat it as a structured classifier and use an internal structure diagram (see paragraph 1.6.2 and paragraph 3.5.1).

The next structural aspect that needs to be discussed is the description of the placement of artifacts in relation to the computing resources involved.

If we are talking about a desktop application that is entirely stored and executed on one computer, then a separate layout diagram is not needed - a component diagram is enough (and perhaps you can do without it). When modeling distributed applications, the importance of placement diagrams increases dramatically: they are a description of the topology ∇ deployed system.

∇ Programmers borrowed the name of the branch of mathematics (topology) as a term. For example, you can often come across the expression “local network topology”. It cannot be said that such borrowing is completely incorrect, but at the same time it is not entirely in essence. We are simply talking about describing the structure of connections of a finite set of nodes, i.e. about the count.

Let us continue our consideration of the HR department information system in this aspect. Let us assume that we have adopted the architecture shown above in the figure "IC Component Diagram OK". How many computers will be used when running this application? This question must also be answered with the question: how many users will the system have and how many of them will work with the application at the same time? If there is only one user (or, worse, our system will be installed “for show” and will not be used), then there is no problem - desktop application - one computer and no placement diagram is needed. Let's say that our system should have many users, and they can work simultaneously. Then the answer is obvious: there should be no fewer nodes than the number of concurrent users, because it is inconvenient for ordinary users to work together on one personal computer. Most likely, there should be one more nodes than users, because Most organizations have a specially dedicated computer (server) for storing corporate data. There we will place our database, in the expectation that the required DBMS is most likely already installed on the server. The question remains about the placement of artifacts that implement business logic. There are different options here: on the user’s computer, on an intermediate machine (application server), on a corporate database server. If we go with the latter option (which in the jargon is called "client/server architecture with a thin client"), we get the diagrams shown in the next two figures.

Both of these diagrams are placement diagrams, but each has its own characteristics. In the first diagram, the emphasis is on indicating the correspondence between components and artifacts, expressed in the presence of a large number of dependency relationships with the stereotype “manifest” (see, for example, 1 in the first diagram). The second diagram shows the relationships between artifacts, or in other words, determines which artifact depends on which, for example, requests data (for an example, see 1 in the second diagram). Both diagrams show compute nodes and the relationships between them (2 in both diagrams). Note that an additional artifact has appeared on the diagram - Help (for example, 3 in the second diagram). This is a document containing background information.

At the end of this section, we will give some tips on when to use component and placement diagrams.

Let's start with the elementary consideration already expressed: in the case of developing a “monolithic” desktop application, layout diagrams are not needed - they turn out to be trivial and do not contain any useful information. Therefore, placement diagrams are only used when modeling multi-component applications.

If an application is supplied in the form of a “constructor” (a set of “cubes”) from which a specific unique instance of the application is assembled during installation, then placement diagrams are simply an indispensable tool. Indeed, many modern applications, especially developed enterprise office management automation systems, are delivered in the form of a large (tens and hundreds) set of artifacts, from which the user-needed, often unique, configuration is assembled “on the spot.” Some authorities recommend using layout diagrams for configuration management not only during the delivery and installation phase of software, but also during the development process: to track component versions, build options, etc.

When developing applications that need to interact with so-called inherited(legacy) applications and data, it is difficult to do without component diagrams. The fact is that virtually the only UML tool that allows you to somehow describe and include legacy applications and data in a model is components (and their interfaces). This also includes the case of modeling access to data from a “non-native” DBMS.

The last (in our list) example of the use of placement diagrams is the modeling of dynamic architecture systems, that is, systems that change the composition and number of instances of their artifacts during execution ∇. For example, many web applications change their configuration at runtime depending on the current load. The HR information system is not a dynamic architecture system, so we do not provide an example.

∇ Note again that at runtime we are not dealing with the classifiers themselves, but with their instances. Section 3.5.4 is devoted to the representation of classifier instances.

A UML diagram is a specialized graphical description language designed for object modeling in the development of various software. The language has a broad profile and is an open standard that uses various graphical notations to create an abstract model of a system. UML was created to enable the 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 provides the possibility of generating separate code based on it.

Why is it needed?

The use of UML does not end with modeling all kinds of software. Also, this language is actively used today for modeling various business processes, conducting system design, and also displaying organizational structures.

With UML, software developers can provide complete agreement in the graphical notation used to represent common concepts such as: component, generic, class, behavior, and aggregation. Due to this, a greater degree of concentration on architecture and design is achieved.

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

Class diagram

A UML class diagram is a static structural diagram designed to describe the structure of a system, as well as show the attributes, methods, and dependencies among 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 subject area, and it provides only classes of application objects.
• 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 completely static structure diagram. It is intended to demonstrate the breakdown of a particular software system into various structural components, as well as the connections between them. A UML component diagram can use all sorts of models, libraries, files, packages, executables, and many other elements as such.

Composite/Composite Structure Diagram

A 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 located in the internal structure of the class.

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

It is worth noting that the UML class and composite structure diagram views can be used simultaneously.

Deployment diagram

This diagram is used to model running nodes, as well as all kinds of artifacts that were deployed on them. In UML 2, artifacts are deployed to various nodes, while in the first version, only components were deployed. Thus, the UML deployment diagram is used primarily for the second version.

A manifestation dependence 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 fully displays all instances of classes of a particular system, indicating the current values ​​of their parameters, as well as the connections between them.

Package diagram

This diagram is structural in nature, and its main content is all kinds of packages, as well as the relationships between them. In this case, there is no strict division between several structural diagrams, as a result of which their use is most often found solely for convenience, and does not carry any semantic meaning. It's 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 a given system.

Activity diagram

A UML activity diagram depicts the decomposition of a specific activity into several component parts. In this case, the concept of “activity” is 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 flows 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 computing. Among other things, they simulate all kinds of technological procedures.

Machine diagram

This type is also called a little differently - UML state diagram. It has a presented finite state machine with simple and composite states, as well as transitions.

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

So-called dragon diagrams can be used as analogues of such diagrams.

Use case diagrams

A UML use case diagram depicts all the relationships that occur between the actors as well as the different use cases. Its main task is to provide a full-fledged means through which the customer, end user or any developer can jointly discuss the behavior and functionality of a certain system.

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

• Clearly separate the system being modeled 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 a given system.

If a usage diagram is developed in UML, the procedure begins with a text description, which is obtained when working with the customer. It is worth noting the fact that various non-functional requirements are completely omitted in the process of drawing up a use case model, and a separate document will be generated for them.

Communications

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

The communication diagram reflects the interactions that occur between the various elements of the composite structure, as well as the roles of cooperation. The main difference between it and a sequence diagram is that it makes the relationships between several elements quite explicit and does not use time as a separate dimension.

This type is distinguished by an absolutely free format for arranging several objects and connections in the same way as is done in an object diagram. If there is a need to maintain the order of messages in this free format, they are numbered chronologically. Reading of this diagram begins with the initial message 1.0, and subsequently continues in the direction in which messages are transmitted from one object to another.

For the most part, these diagrams show exactly the same information that a sequence diagram provides us with, but 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 what elements each individual element interacts with, while a sequence diagram more clearly shows in what order the interactions occur.

Sequence diagram

A UML sequence diagram shows interactions between multiple objects that are ordered according to the time they occur. This diagram shows the time-ordered interaction between several objects. In particular, it displays all the objects that take part in the interaction, as well as the complete sequence of messages exchanged between them.

The main elements in this case are the designations of various objects, as well as vertical lines depicting the passage of time and rectangles representing the activity of a certain object or the performance of some function.

Cooperation diagram

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

Because sequence 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, and also synchronizes them completely automatically.

Interaction overview diagrams

These are UML diagrams that are a type of activity diagram and include both Sequence elements and control flow constructs.

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

Timing diagram

Represents an alternative version of a sequence diagram that explicitly demonstrates the change in state along a lifeline over a specific time scale. Can be quite useful in various real-time applications.

What are the advantages?

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

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

Flaws

Despite the fact that constructing UML diagrams has a lot of advantages, they are often criticized for the following disadvantages:

• Redundancy. In the vast majority of cases, critics say that UML is too large and complex, and this is often unjustified. It includes quite a lot of redundant or practically useless designs and diagrams, and most often such criticism is directed at the second version, not the first, because newer revisions contain more “designed by committee” compromises.
• Various inaccuracies in semantics. Because UML is defined by a combination of itself, English and OCL, it does not have the rigidity that is inherent in languages ​​precisely defined by formal description techniques. In certain situations, the abstract syntax of OCL, UML, and English begin to contradict each other, while in other cases they are incomplete. Inaccuracy in the specification of the language itself impacts both users and tool vendors alike, ultimately leading to tool incompatibility due to the unique way different specifications are treated.
• Problems in the process of implementation and study. All of the above issues create challenges in implementing and learning UML, especially when management forces engineers to use it without prior knowledge.
• The code reflects 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. According to this view, there is a need to develop a more efficient way of writing software. UML is commonly valued in 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 code generated will ultimately be limited to what the UML interpreting tool can guess or determine.
• Load mismatch. This term comes from the theory of systems analysis to determine the inability of the input of a certain system to perceive another output. As with any standard notation, UML can represent some systems more efficiently and concisely than others. Thus, the developer is more inclined towards those solutions that are more comfortable in interweaving all the strengths of UML, as well as other programming languages. This problem is more obvious if the development language does not conform to the basic principles of object-oriented orthodoxy, that is, it does not try to work in accordance with the principles of OOP.
• Tries to be universal. UML is a general-purpose modeling language that tries to be compatible with any processing language available today. In the context of a given project, in order for the design team to achieve the final goal, it is necessary to select the applicable features of that language. In addition, possible ways to limit the scope of UML in a particular area are through a formalism that is not fully articulated and which itself is subject to criticism.

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