The Unified Modeling Language (UML) is a language for specifying, visualizing, designing 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 in modeling large and complex systems.

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

        UML provides expressive tools for creating visual models that:

  • are uniformly understood by all developers involved in the project;
  • are the 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 source and has the means to extend the underlying core. In UML, classes, objects, and components can be meaningfully described in various subject areas, often very different from each other.

UML Diagrams

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

  • Use case diagram (diagrams of precedents);
  • Deployment diagram (topology diagrams);
  • Statechart diagram (state diagrams);
  • Interaction diagram (interaction diagrams); Activity diagram (activity diagrams);
  • Sequence diagram (diagrams of sequences of actions);
  • Collaboration diagram (collaboration diagrams);
  • Class diagram (class diagrams);
  • Component diagram (component diagrams);
  • Behavior diagrams (diagrams of behavior);
  • Activity diagram (activity diagram);
  • Implementation diagrams (implementation diagrams);

        Each of these diagrams fleshes out a different view of the system model. At the same time, the use case diagram represents the conceptual model of the system, which is the starting point for constructing all other diagrams. The class diagram is a logical model that reflects the static aspects of the structural construction of the system, and behavior diagrams, which are also varieties of the 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. As independent representations, the following diagrams are used: use cases, classes, states, activities, sequence, cooperation, components, and deployment.

        There are three types of visual cues for UML diagrams that are important in terms of the information they contain:

  • connections, which are represented by different lines on the plane;
  • text, contained within the boundaries of individual geometric shapes;
  • graphic symbols, displayed near chart visuals.

        When graphical representation of 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 entities of the model presented in the diagram must be of the same conceptual level;
  • all information about entities must be explicitly presented in the diagram;
  • diagrams should not contain conflicting information;
  • diagrams should not be overloaded with textual information;
  • each diagram must be self-sufficient for the correct interpretation of all its elements;
  • the number of diagram types required to describe a particular system is not strictly fixed and is determined by the developer;
  • system models should contain only those elements that are defined in the notation of the UML language.

Entities in the UML

        The UML defines four entity types: structural, behavioral, grouping and annotational. Entities are the main object-oriented elements of the language, with the help of which models are created.

        Structural entities are nouns in UML models. As a rule, they represent static parts of the model, corresponding to the conceptual or physical elements of the system. Examples of structural entities are "class", "interface", "cooperation", "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 determines the 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 the blocks into which the model can be decomposed. There is only one such primary entity - it is a package.

        Packages are a general mechanism for organizing items 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 development.

        Annotation Entities are explanatory parts of the UML model: comments for additional description, clarification or remarks on any element of the model. There is only one base type of annotation elements - note. A note is used to provide comments or restrictions on diagrams, expressed as informal or formal text.

Relationships in the UML

        The UML defines the following relationship types: dependency, association, generalization and implementation. These relationships are the basic binding constructs of the UML, and the same way entities are used 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 the totality of semantic or logical relationships between objects.

        Generalization is a relationship in which a specialized element object (child) can be substituted for a generic element object (ancestor). At the same time, in accordance with the principles of object-oriented programming, the child (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 relation occurs in two cases:

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

General UML mechanisms

        UML uses so-called general mechanisms to accurately describe a system:

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

        UML is not only a graphical language. Behind each graphic element, its notation is specification A that contains the textual representation of the corresponding language construct. For example, a class icon 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 have another representation of this class, reflecting completely different aspects of it, but, nevertheless, corresponding to the specification. Thus, UML graphical notation is used to visualize the system, and with the help of specifications describe its details.

        Almost every UML element has a unique graphic that gives a visual representation of its most important characteristics. The "class" entity notation 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 the standard rectangle that represents the class.

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

        First, there is a division into classes and objects. A class is an abstraction, and an object is a concrete implementation of that abstraction. In this regard, almost all language constructs are characterized by the "class/object" duality. Thus, there are use cases and instances of use cases, components and instances of components, nodes and instances of nodes. In 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. The interface declares the obligations, and the implementation represents the concrete implementation of these obligations and ensures that the declared semantics are followed exactly. As such, almost all UML constructs are characterized by interface/implementation duality. For example, use cases are implemented by collaborations, while operations are implemented by methods.

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

        UML extension mechanisms include:

  • stereotypes (stereotype) - expand the vocabulary of UML, allowing you to create new ones based on existing elements of the language, focused on solving a specific problem;
  • tagged values ​​- extend the properties of the basic UML constructs, allowing you to include additional information in the element specification;
  • constraints (constraints) - extend 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 according to the needs of the project or the peculiarities of the development technology.

Use Case Diagram

        This type of chart 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 system requirements is created and a set of functions performed by the system is determined.


Figure - 1. Use Case Diagram

        Use case diagrams describe the functionality of the system or what the system should 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 interacting with the system using use cases. In this case, an actor (actor) or an actor is any entity that interacts with the system from the outside. It 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 in the way that the developer himself determines. 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 piece of behavior of an entity without exposing 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, determines how the entity is 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 for the next requests.

        Use cases can be used both to specify external requirements for a 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 establish requirements that determine how actors must interact with the system in order to be able to work correctly with the provided services. For convenience, many use cases can be considered as a separate package.

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

Class diagram (class diagram)

        Central to object-oriented programming is the development of a logical model of a system in the form of a class diagram. Class diagram (class diagram) serves to represent the static structure of the system model in the terminology of object-oriented programming classes. A class diagram can reflect, in particular, various relationships between individual entities of the subject area, 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 various notations. cloud-like. 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 the UML, it is used to denote a set of objects that have the same structure, behavior, and relationships with objects of other classes. Graphically, the class is depicted as a rectangle, which can additionally be divided by horizontal lines into sections or sections. These sections can contain the class name, attributes (variables), and operations (methods).

State diagram (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 state of an object as its reaction to external influences.

        Statecharts 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 graph of a special kind that represents some automaton. The vertices of the graph are the possible states of the automaton, depicted by the corresponding graphic symbols, and the arcs indicate its transitions from state to state. Statecharts can be nested to provide a more detailed representation of individual model elements.

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

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

        The behavior of the automaton is modeled as a 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 vending machine:

  • the state into which an object can go is determined only by its current state and does not depend on its history;
  • at any given time, the automaton can only be in one of its states. At the same time, the automaton can be in a separate state for an arbitrarily long time if no events occur;
  • the time spent by the automaton in one state or another, as well as the time it takes to reach one state or another, are not specified in any way;
  • the number of automaton states must be finite, and all of them must be explicitly specified. 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 in question;
  • the automaton graph must not contain isolated states and transitions. For each state, except for the initial one, the previous state must be defined, and each transition must connect two states of the automaton;
  • the automaton should not contain conflicting transitions when the object can simultaneously go to two or more subsequent states (except for the case of parallel subautomata). In the UML language, conflict elimination is possible based on the introduction of guard conditions.

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

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

Activity diagram

        When modeling the behavior of a designed or analyzed system, 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 object being modeled, however, the main purpose of the Activity diagram is to reflect the object's business processes. This type of diagram allows you to show not only the sequence of processes, but also branching and even synchronization of processes.

        This type of diagram allows you to design algorithms for the behavior of objects of any complexity, and can also be used to create block diagrams.

        UML uses activity diagrams to model the process of performing operations. Their graphical notation is similar in many ways to statechart notation, since these diagrams also have state and transition symbols. Each state in the activity diagram corresponds to the execution of some elementary operation, and the transition to the next state is performed 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 the features of procedural and synchronous control, due to the completion of internal activities and actions. The main direction of using activity diagrams is to visualize the features of the implementation of class operations, when it is necessary to present algorithms for their execution.

        In the context of the UML activity is a set of individual calculations performed by the automaton, leading to some result or action (action). The activity diagram shows the logic and sequence of transitions from one activity to another, and the analyst's attention is focused 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 state exit transition. 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 a single 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 the behavior of systems, time is not explicitly present in them. The temporal aspect of behavior can be of significant importance when modeling synchronous processes that describe the interactions of objects. Sequence diagrams are used to model the interaction of objects in time in the UML language.

        Sequence diagrams show only those objects that are directly involved in the interaction. The key point for sequence diagrams is the dynamics of the interaction of objects over time.

        In UML, a sequence diagram has two dimensions, as it were. The first from left to right as vertical lines, each of which depicts the lifeline of an individual object participating in the interaction. The leftmost object in the diagram is the object that is the initiator of the interaction. To the right, another object is depicted, which directly interacts with the first one. Thus, all objects in the sequence diagram form a certain order, determined by the order or degree of activity of objects when interacting with each other.

        Graphically, each object is represented by a rectangle and is located at the top of its lifeline. Inside the rectangle, the name of the object and the name of the class are written separated by a colon. In this case, the entire record is underlined, which is a sign of the object.

        The second dimension of a sequence diagram is the vertical time axis, from top to bottom. The topmost part of the diagram corresponds to the initial moment of time. Object interactions are realized through messages that are sent by one object to another. Messages are displayed as horizontal arrows with the name of the message, and their order is determined by the time they occurred. That is, messages higher up in the sequence diagram are initiated before those lower down. 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 the cooperation diagram is the ability to graphically represent not only the sequence of interaction, but also all the structural relationships between the objects involved in this interaction.


Figure - 3. Diagram of cooperation

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

        First of all, on the diagram of cooperation, 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. 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 links can be displayed - message flows. They are also represented as connecting lines between objects, above which there is an arrow indicating the direction, message name and serial number in the general sequence of message initialization.

        Unlike a sequence diagram, a collaboration diagram only shows relationships between objects that play specific roles in an interaction. This chart does not show time as a separate dimension. Therefore, the sequence of interactions and parallel flows can be defined using sequence numbers. Therefore, if it is necessary to explicitly specify relationships between objects in real time, it is better to do so in a sequence diagram.

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

        Cooperation can be represented on two levels:

  • specification level - shows the roles of classifiers and the role of associations in the considered interaction;
  • instance level - indicates the instances and relationships that form the individual roles in the collaboration.

        A specification-level collaboration 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 separate roles of classifiers and associations between participants in the cooperation.

        An instance-level collaboration diagram is represented by a collection of objects (class instances) and relationships (association instances). At the same time, the links are supplemented with message arrows. At this level, only objects that are directly related to the implementation of the operation or classifier are displayed. In this case, it is not at all necessary to depict all properties or all associations, since only the roles of classifiers are present on the cooperation diagram, but not the classifiers themselves. Thus, while the classifier requires a complete description of all its instances, the role of the classifier requires the description of only those properties and associations that are necessary to participate in a particular cooperation.

        An important corollary follows from this. The same set of objects can participate in different collaborations. Depending on the cooperation under consideration, both the properties of individual objects and the links 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 used to allocate classes and objects to components in the physical design of the system. This type of diagram is often referred to as module diagrams.



Figure - 4. Diagram of components

        A complete software system design is a combination of models of the logical and physical levels, which must be coordinated with each other. In the UML language, for the physical representation of system models, implementation diagrams (implementation diagrams) are used, which include component diagram and deployment diagram.

        A component diagram, in contrast to 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 the reuse of individual fragments of program code;
  • representations of the conceptual and physical schemas of databases.

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

        UML uses a special term to represent physical entities - component. The component implements a certain set of interfaces and serves as a general designation of the elements of the physical representation of the model. For the graphical representation of the 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 image of this symbol may vary slightly depending on the nature of the information associated with the component.

Deployment diagram

        This type of diagram is designed to analyze the hardware of the system, that is, the hardware, not software. In direct translation 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 about 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 the problems of rational placement of components in order to effectively use distributed computing and communication network resources, ensure security, and others.

        UML uses deployment diagrams to represent the overall configuration and topology of a distributed software system.

        Deployment diagram is designed to visualize elements and components of a program that exist only at the stage of its execution (runtime). In this case, only program instance components that are executable files or dynamic libraries are presented. Those components that are not used at runtime are not shown in the deployment diagram. So, components with program source codes can only be present on the component diagram. They are not shown on the deployment diagram.

        A deployment diagram contains graphical representations of processors, devices, processes, and their relationships. Unlike logical representation diagrams, the deployment diagram is the same for the system as a whole, since it must fully reflect the features of its implementation. The development of a deployment diagram is usually the last step in the specification of a software system model.

        When designing a deployment diagram, the goals are:

  • determine the distribution of system components over 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 engineers.

Features of the Rational Rose desktop 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 almost no difficulties even for beginners, running this program in the MS Windows 95/98 environment leads to the appearance of a working interface on the screen (Fig. 6).


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

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

  • Main menu of the program
  • Chart 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 has the following form (Fig. 7).

Separate 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 the clipboard and pasting various diagram elements from the clipboard). Others are so specific that they may require additional effort to learn (options for generating program code, checking the consistency of models, 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 items). The standard toolbar provides quick access to those menu commands that are used most often by developers.

Figure - 8. Appearance of the standard toolbar

The user can customize the appearance of this panel at his discretion. To do this, select the menu item Tools -> Options (Tools -> Options) and open the tab Toolbars (Toolbars). In this way, you can show or hide various tool buttons, as well as 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 makes it easier to navigate and 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 placed in another place of the working interface, or hidden altogether, using the menu item View (View). You can also resize the browser by dragging the border of its outer frame with the mouse.

Figure - 9. Browser appearance

Special toolbar

A special toolbar is located between the browser window and the diagram 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

You can change the location of the custom toolbar by moving the frame of the toolbar 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 found in tooltips that appear after hovering the mouse pointer over the corresponding button.

Chart window

The diagram window is the main working area of ​​its interface, in which various representations of the project model are visualized. By default, the chart window is located on the right side of the work 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 diagram window. Several diagrams can be present in the diagram window at the same time, but only one of them can be active. For example, in fig. 11 the deployment diagram is the active one, although there are other diagrams. Switching between diagrams can be done by selecting the desired view on the standard toolbar or through the menu item Window (Window). When an individual chart view is activated, the appearance of a special toolbar changes, which is customized for a specific chart view.


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

Documentation window

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

The documentation window, as its name implies, is intended for documenting the elements of the model view. It can record a variety of information, and what is important - in Russian. This information is subsequently converted into comments and does not affect the logic of program code execution in any way.

The documentation window activates the information that relates to a single selected element of the diagram. In this case, you can select an element either in the browser window or in the diagram window. When a new element is added 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 (Log) is intended for automatic recording of various service information generated during the work with the program. The log records the time and nature of developer actions, such as updating the model, customizing menus and toolbars, and reporting errors that occur during code generation.

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

Figure - 13. Log window appearance

Conclusion

        Over time, the UML language will become that "Esperanto" that mathematicians, system analysts, physicists, programmers, managers, economists and specialists of other professions can communicate in, presenting their professional knowledge in a unified form. Indeed, in essence, each of the specialists operates with model representations in his field of knowledge. And it is this model aspect that can be specified by means of the UML language.

        In this regard, the importance of the UML language increases significantly, as it increasingly acquires 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 a 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 talks about the new age of software development, its impact on the new requirements put forward to the UML, and the best methods for fulfilling them.
  7. "Data modeling in Rational Rose" Sergey Trofimov Describes how to model the physical representation of data using Rational Rose
  8. UML language. General understanding of the UML language: structures, graphic elements and diagrams of the language.
  9. Practical UML. This document is a translation of the "Practical UML. A Hands-On Introduction for Developers" document. A Practical Introduction for Developers
  10. "Standard object-oriented modeling language UML" Vendrov Alexander Mikhailovich. History of UML creation
  11. UML - Unified Modeling Language. This material contains initial information about the methods of describing software systems and notations used in UML
  12. UML language. User's manual. 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 a description of the subject area using UML in the development of software systems" E.B. Zolotukhina, R.V. Alfimov. The article demonstrates a possible approach to domain modeling based on the use of the Unified Modeling Language (UML) using a specific example.

       

Show the behavior of one object during its lifetime, from the creation of the object to its destruction. Each state diagram represents some automaton.

Action plan

In the Description section, learn about the basic statechart character set needed to be able to read diagrams.

After reading the other sections ("Example", "Usage"), you can try your hand at creating state diagrams on your own.

Notes (description)

Here is the main character set state diagrams needed to be able to read the diagram. After reading the other sections ("Example", "Application"), you will be able to compose state diagrams on one's own!

Term Image Description
Initial pseudostate Initial state of the system
Transition Transition means moving from one state to another.
State Denotes the actions performed by the system (may include possible options) that lead to the results observed by the actors.
State
activity state		 A difficult step in a use case can be represented by another use case.
In UML terms, we say that the first use case includes the second.
End state Allows you to designate the boundaries of systems or subsystems.
Internal activities The case where states can respond to events without making a transition, in which case the event, guard, and activity are placed inside the state rectangle.
input activity The entry activity is executed whenever you enter the state
output activity Exit activity - executed whenever you leave the state.
superstate
It often happens that several states have common transitions and internal activities. In such cases, you can turn them into substates (substates), and transfer the overall behavior to a superstate (superstate).
Parallel States
States can be broken down into multiple concurrent states that run at the same time.

How to apply the technique of creativity

UML state diagrams are good for describing the behavior of a single object across multiple use cases. But they are not very suitable for describing behavior characterized by the interaction of many objects. Therefore, it makes sense to use other technologies in conjunction with state diagrams. For example, interaction diagrams (Chapter 4) are great at describing the behavior of multiple objects in a single use case, while UML activity diagrams are good for showing the main sequence of actions of several objects in several use cases.

Not everyone considers state diagrams to be natural. Watch how the experts work with them. It's possible that your team members don't think statecharts are right for their way of working. This is not the biggest difficulty; you must remember to share different working methods.

If you use statecharts, don't try to draw them for every class in the system. This approach is often used for the sake of formally rigorous completeness, but it is almost always a waste of effort. Use statecharts only for classes that exhibit interesting behavior, where plotting the statechart helps you understand how things are going.

Many experts believe that the UI editor and control objects have functionality useful when displayed with a statechart.

How to learn

Here we have tried to provide the easiest way to learn UML state diagrams.

Like many other languages, it uses a set of characters to describe. The meaning of these symbols can be found in the table in the "Notes (description)" section. Each sign has its own name (term) and spelling. Also, each term is provided with a brief explanation to quickly understand its main essence.

Next, we would recommend going to the "Examples" section state diagrams to try your hand at reading different charts. Then you should study the "Usage" section, because, although the number of diagram types in the UML is small, you can get the maximum benefit from using them only if you use the appropriate diagrams for their intended purpose.

Usage example

State machine diagrams is a well-known technique for describing the behavior of a system. State diagrams have been around in one form or another since the 1960s, and in the early days of object-oriented programming, they were used to represent the behavior of a system. In object-oriented approaches, you draw a state diagram of a single class to show the behavior of a single object during its lifetime.

Whenever finite state machines are written about, cruise control systems or vending machines are inevitably cited as examples.
We decided to use the controller of the secret control panel in the Gothic Castle. In this castle, we want to hide our treasures so that they are hard to find. In order to gain access to the lock of the safe, we must pull out a strategic candle from the candelabra, but the lock will appear only if the door is closed. After the lock appears, we can insert the key into it and open the safe. For added security, we have made it so that the safe can only be opened after the candle has been removed. If the thief fails to heed this precaution, then we will unleash a hideous monster who will swallow the thief.

On fig. 10.1 shown state diagram controller class that manages my unusual security system. The state diagram starts with the state of the controller object being created: states Wait. This is indicated on the diagram with initial pseudostate, which is not a state, but has an arrow pointing to the initial state.
The diagram shows that the controller can be in one of three states: Wait (Waiting), Lock (Lock) and Open (Opened). The diagram also shows the rules according to which the controller transitions from one state to another. These rules are represented as transitions - lines connecting states.

Transition means moving from one state to another. Each transition has its own label, which consists of three parts:
trigger-identifier [protection]/activity (trigger-signature /activity). All of them are optional. Usually, trigger-id is the only event that can cause a state change.

The guard, if specified, is a logical condition that must be met for the transition to take place. Activity is some behavior of the system during the transition. It can be any behavioral expression. The full form of an ID trigger can include multiple events and parameters. The transition from the Wait state (Fig. 10.1) to another state can be read as “In the Wait state, if the candle is removed, you see a lock and go to the Lock state.”

All three parts of the transition description are optional. Skipping activity means that nothing happens during the transition. Skip guards means that the transition is always executed if the triggering event occurs. The trigger identifier is rarely missing, but it happens. This means that the transition occurs immediately, which can be observed mainly in active states.

When an event occurs in a certain state, then only one transition can be made from this state, for example, in the Lock state (Fig. 10.1), protections must be mutually exclusive. If an event occurs and there are no allowed transitions—for example, closing a safe in the Wait state, or removing a candle while the door is open—the event is ignored.

End state ( final state) means that the state machine has finished running, which causes the controller object to be deleted. So for those of you who weren't careful enough to fall into the trap, as the controller object ceases to exist, we're forced to put the rabbit back in its cage, mop the floor, and reboot the system.

Remember that state machines can only show objects that are directly observed or acted upon. So while you might expect us to put something in or take something out of the safe when the door is open, we didn't mark it on the diagram because the controller can't tell us anything about it.

When developers talk about objects, they often refer to the state of the objects, meaning a combination of all the data contained in the object's fields. However, state in a state machine diagram is a more abstract notion of state; the point is that different states imply different ways of reacting to events.

Internal activities in a statechart

States can respond to events without making a transition using internal activities (internal activities), in which case the event, guard, and activity are placed inside the state rectangle.

On fig. Figure 10.2 shows the state with internal symbol activities and help system events that you can observe in the text fields of the editor. UI. An inner activity is like a self-transition - a transition that returns to the same state. The syntax of internal activities is built according to the same logical scheme of events, protections and procedures.

On fig. 10.2 also shows special activities: input and output activities. input activity executed whenever you enter the state; output activity– whenever you leave the state. However, internal activities do not initiate input and output activity; this is the difference between internal activities andself-transitions .

Activity states in a statechart

In the states we've described so far, the object is silent and waits for the next event before doing anything. However, states are possible in which the object exhibits some activity.

State Searching in fig. 10.3 is such a state activity state: ongoing activity is indicated by the symbol do/; hence the term do activity (be active). After the search is completed, transitions with no activity are performed, such as showing new equipment (Display New Hardware). If a cancel event occurs during the activity ( cancel), then do-activity is simply interrupted and we return to the state Update Hardware Window.

Both do-activities and normal activities represent the manifestation of some behavior. The crucial difference between the two is that regular activities happen "instantly" and cannot be interrupted by regular events, while do activities can run for some limited time and can be interrupted, as shown in Figure 2. 10.3. Instantaneity for different systems is interpreted differently; for real-time systems, this can take several machine instructions, and for desktop software, it can take several seconds.

AT UML 1 ordinary activities were denoted by the term action(action) and the term activity(activity) was used only for do-activities.

Superstates

It often happens that several states have common transitions and internal activities. In such cases, you can turn them into substates (substates), and transfer the overall behavior to a superstate (superstate), as shown in Fig. 10.4. Without the superstate, we would have to draw the transition cancel(cancel) for all three states within a state Enter Connection Details.

Parallel States

States can be broken down into multiple concurrent states that run at the same time. On fig. Figure 10.5 shows a simple alarm clock that can turn on either a CD or a radio and show either the current time or the signal time.

CD/radio options and current time/alarm time are parallel. If you wanted to represent this with a non-parallel state diagram, you would end up with a messy diagram as states need to be added. Splitting the two behaviors into two state diagrams makes it much clearer.

Rice. 10.5 includes also prehistory state(history pseudostate). This means that when the clock is turned on, the radio/CD option changes to the state the clock was in when it was turned off. An arrow coming out of history shows which state existed originally when there was no history.

Implementing statecharts

A state diagram can be implemented in three main ways: using a nested switch statement, the State pattern, and a state table. The most direct approach to working with statecharts is a nested switch statement, such as the one in Figure 1. 10.6.

Although this method is straight forward, it is very long even for this simple case. In addition, with this approach it is very easy to lose control, so we do not recommend using it even in elementary situations.
The State pattern represents a hierarchy of state classes for handling state behavior. Each state in the statechart has its own state subclass. The controller has methods for each event that simply redirect to the state class. The state diagram shown in fig. 10.1 could be implemented using the classes shown in Fig. 10.7.

The top of the hierarchy is an abstract class that contains a description of all methods that handle events, but no implementation.
For each specific state, it is enough to rewrite the handler method of a specific event that initiates the transition from the state.
The state table represents the state diagram as data.

So, the diagram in Fig. 10.1 can be presented in the form of a table. 10.1.
Then we build an interpreter that uses the state table during program execution, or a code generator that generates classes based on this table.

Obviously, most of the work on the state table is done once, but then it can be used whenever you need to solve a state-related problem. The run-time state table can be modified without recompilation, which is somewhat convenient. The state template is easier to assemble, and although each state requires a separate class, the amount of code that must be written is quite small.

The implementations given are almost minimal, but they give an idea of ​​how to apply state diagrams. In each case, the implementation of the state models results in a fairly stereotypical program, so it's usually better to use some form of code generation for this.

Subscribe to site news, you can find the subscription form in the right column of the site.

If you want to learn how to freelance professionally, we invite you to the course "".

UML is a unified graphical modeling language for describing, visualizing, designing and documenting OO systems. UML is designed to support the process of PS modeling based on the OO approach, to organize the relationship between conceptual and program concepts, and to reflect the problems of scaling complex systems. UML models are used at all stages of the software life cycle, from business analysis to system maintenance. Different organizations can use the UML in their own way, depending on their problem areas and the technologies used.

A Brief History of UML

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

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

UML is a language

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

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

UML vocabulary

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

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

Relations show different relationships between entities. The following types of relationships are defined in the UML:

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

Diagrams. The UML provides the following diagrams:

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

Model control view. Packages.

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

What UML provides.

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

And the last…

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

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

Benefits of UML

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

Types of UML Diagrams

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

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

Hierarchy of UML diagram types, represented by a class diagram

Structural diagrams

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

UML Class Diagram Example

Behavior Diagrams

  1. activity diagram shows actions ( actions) of which some activity ( activity). Activity diagrams are used to model business processes, technological processes, serial and parallel computing.
  2. Use case diagram(or use case diagram) describes the relationship between actors (actors) and use cases of the simulated system (its capabilities). The main purpose of the diagram is to be a universal tool for customers, developers and end users, with the help of which it would be possible to jointly discuss the system - its capabilities and behavior.
  3. State diagram depicts the dynamic behavior of an entity, showing how this entity, depending on its current state, reacts to various events. In fact, this is a state diagram from the theory of atoms.
  4. Communication Diagram(in earlier versions cooperation diagram) shows the interactions between parts of the composite structure and collaboration roles. The diagram explicitly indicates the relationship between elements (objects).
  5. sequence diagram used to visualize the sequence of object interactions. Shows the life cycle of a given object and the interaction of actors (actors) within some use case, the sequence of messages that they exchange.
  6. Interaction Overview Diagram includes part of the sequence diagram and control flow construct. Helps to consider the interaction of objects from different points of view.
  7. Timing chart- a separate subspecies of interaction diagrams, specializing in timing. Diagrams of this type are used to study the behavior of objects over a certain period of time.
11.1. Structure of the Unified Modeling Language

Unified Modeling Language (UML) is currently the de facto standard for describing (documenting) the results of designing and developing object-oriented systems. UML development began in 1994 by Grady Booch and James Rumbaugh at Rational Software. In the fall of 1995, Ivar Jakobson joined them and in October of the same year, a preliminary version of the 0.8 Unified Method was released. Since that time, several versions of the UML specification have been released, two of which have the status of an international standard:

UML 1.4.2 - "ISO/IEC 19501:2005. Information technology. Open distributed processing. Unified modeling language (UML). Version 1.4.2");

UML 2.4.1 - "ISO / IEC 19505-1: 2012. Information technology. Unified object management group modeling language (OMG UML). Part 1. Infrastructure" (eng. "Information technology -- Object Management Group Unified Modeling Language ( OMG UML) - Part 1: Infrastructure") and "ISO / IEC 19505-2: 2012. Information technology. Unified object management group modeling language (OMG UML). Part 2. Superstructure" (eng. "Information technology - Object Management Group Unified Modeling Language (OMG UML) - Part 2: Superstructure").

The latest official language specification can be found at www.omg.org.

The general structure of the UML is shown in the following figure.

Rice. 11.1. UML structure

11.2. Semantics and Syntax of UML

Semantics - a section of linguistics that studies the meaning of units of a language, primarily its words and phrases.

Syntax - ways to connect words and their forms into phrases and sentences, connect sentences into complex sentences, ways to create statements as part of the text.

Thus, in relation to UML, semantics and syntax determine the style of presentation (building models), which combines natural and formal languages ​​to represent basic concepts (elements of the model) and mechanisms for their extension.

11.3. UML notation

Notation is a graphical interpretation of semantics for its visual representation.

The UML defines three entity type :

Structural - an abstraction that is a reflection of a conceptual or physical object;

Grouping - an element used for some semantic association of diagram elements;

Explanatory (annotational) - a comment to a diagram element.

The following table provides a brief description of the main entities used in graphical notation and the main ways to display them.

Table 11.1. Essences

Type of Name Designation Definition (semantics)
Structural
(class)		 A set of objects that share a common structure and behavior

(object)		 An abstraction of a real or imaginary entity with well-defined conceptual boundaries, individuality (identity), state and behavior. From the UML point of view, objects are class instances (entity instances)

(actor)
Engineer
path services		 An entity external to the system that interacts with the system and uses its functionality to achieve certain goals or solve particular problems. Thus, an actor is an external source or receiver of information.

(use case)		 Description of the actions performed by the system, which leads to a result that is significant for the actor

(state)		 Description of the moment in the life of an entity when it satisfies some condition, performs some activity, or waits for some event to occur.
Cooperation
(collaboration)		 Description of a set of instances of actors, objects and their interaction in the process of solving a certain problem

(component)		 The physical part of the system (file), including system modules that provide the implementation of a consistent set of interfaces

(interface)
iCalculation		 A set of operations that defines a service (set of services) provided by a class or component

(node)		 The physical part of the system (computer, printer, etc.) that provides resources for solving a problem
Grouping
(package)		 General mechanism for grouping elements.
Unlike a component, a package is a purely conceptual (abstract) concept. Special cases of a package are system and model

(fragment)		 Area of ​​Specific Interaction of Actor and Object Instances

(activity partition)		 A group of operations (area of ​​responsibility) performed by a single entity (actor, object, component, node, etc.)

(interruptible activity region)		 A group of operations, the normal sequence of execution of which can be interrupted as a result of an unusual situation
explanatory Note
(comment)		 Element comment. Attached to the commented element with a dashed line

Some sources, in particular [ , ], also distinguish behavioral entities interactions and state machines, but from a logical point of view they should be classified as diagrams.

Some of the above entities in accordance with imply their detailed description in decomposition diagrams. On the top-level diagram, they are marked with a special icon or label.

The following table describes each type relations UML used in diagrams to indicate relationships between entities.

Table 11.3. Relations

Name Designation Definition (semantics)
Association A relationship that describes a meaningful relationship between two or more entities. The most general type of relationship
Aggregation A subtype of an association that describes a "part"–"whole" relationship, in which the "part" can exist separately from the "whole". The rhombus is indicated from the "whole" side. A relationship is specified only between entities of the same type
Composition A subspecies of aggregation in which "parts" cannot exist separately from the "whole". As a rule, "parts" are created and destroyed simultaneously with the "whole"
Dependency A relationship between two entities in which a change in one entity (the independent) can affect the state or behavior of the other entity (the dependent). An independent entity is indicated on the side of the arrow
Generalization The relationship between a generalized entity (ancestor, parent) and a specialized entity (child, daughter). The triangle is indicated from the side of the parent. A relationship is specified only between entities of the same type
Realization A relationship between entities where one entity specifies an action that another entity undertakes to perform. Relationships are used in two cases: between interfaces and classes (or components), between use cases and collaborations. The side of the arrow indicates the entity that defines the action (interface or use case)

For association, aggregation and composition, you can specify multiplicity (English multiplicity), which characterizes the total number of instances of entities participating in the relationship. It, as a rule, is indicated on each side of the relationship near the corresponding entity. Multiplicity can be specified in the following ways:

- * - any number of copies, including none;

Non-negative integer - the multiplicity is strictly fixed and equal to the specified number (for example: 1, 2 or 5);

Range of non-negative integers "first number.. second number" (for example: 1..5, 2..10 or 0..5);

A range of numbers from a specific initial value to an arbitrary final "first number..*" (for example: 1..*, 5..*, or 0..*);

Enumeration of non-negative integers and ranges separated by commas (for example: 1, 3..5, 10, 15..*).

If the multiplicity is not specified, then its value is assumed to be 1. The multiplicity of entity instances involved in dependency, generalization, and implementation is always assumed to be 1.

The following table provides a description expansion mechanisms used to refine the semantics of entities and relationships. In general, the expansion mechanism is a string of text enclosed in parentheses or quotation marks.

Table 11.4. Extension mechanisms

Name Designation Definition (semantics)
Stereotype
(stereotype)		 « » A designation that specifies the semantics of the notation element (for example: a dependency with the “include” stereotype is considered as an inclusion relation, and a class with the “boundary” stereotype is a boundary class)
guard condition
(guard condition)		 Boolean condition (for example: or [identification done])
Limitation
(constraint)		 { } A rule that restricts the semantics of a model element (for example, (execution time less than 10 ms))
Marked value
(tagged value)		 { } A new or qualifying notation element property (for example: (version = 3.2))

In addition to stereotypes specified as a string of text in quotation marks, graphical stereotypes can be used in charts. The following figure shows examples of standard and stereotype mapping.

a) standard designation b) standard designation
with text stereotype		 c) graphic stereotype

Rice. 11.2. Examples of standard and stereotypical class mapping

Diagram is a grouping of notation elements to display some aspect of the information system being developed. Diagrams are usually a connected graph in which entities are vertices and relationships are arcs. The following table gives a brief description of UML diagrams.

Table 11.5. Diagrams

Diagram Purpose
according to the degree of physical implementation by displaying dynamics by displayed aspect

(use case)		 Displays system functions, interaction between actors and functions logical static functional

(class)		 Displays a set of classes, interfaces and relationships between them Boolean or
physical		 static Functional information

(package)		 Displays a set of packages and their relationships Boolean or
physical		 static Component
behavior
(behavior)
(state machine)		 Displays entity states and transitions between them during its life cycle logical Dynamic behavioral

(activity)		 Displays business processes in the system (description of behavior algorithms)
Interactions
(interaction)
(sequence)		 Displays the sequence of message passing between objects and actors

(communication)		 Similar to a sequence diagram, but the main focus is on the structure of interaction between objects
Implementations
(implementation)
(component)		 Displays system components (programs, libraries, tables, etc.) and links between them Physical static Component

(deployment)		 Displays the placement of components by network nodes, as well as its configuration

The UML 2.x standard also defines additional, highly specialized diagrams:

Object diagram (object diagram) - similar, but objects are displayed instead of classes;

Timing diagram - describes the state of the object over time;

Composite structure diagram - describes the ports (including interfaces) of a class for interacting with other classes;

Profile diagram (profile diagram) - similar to the description of the classes included in them;

Interaction overview diagram - similar, but with hidden interaction fragments (fragments with a ref label). It is a contextual (conceptual) one, the elements of which will be specified on separate decomposition diagrams.

In order to enlarge the conceptual representation of the internal architecture of the system, most of the construction allows the use of well-established graphic stereotypes for the so-called. Such a diagram is called 1 , but does not belong to the list of diagrams defined by the UML standard.

When developing a separate system model, several types of diagrams are built. Moreover, when developing a model of a complex system, as a rule, several diagrams of the same type are built. At the same time, you don't have to create separate chart views if you don't need to. For example, diagrams and are interchangeable; they are built only for objects with complex behavior. The following table provides recommendations on the need to develop (refine) diagrams for system models.

Table 11.6. Linking Models and Diagrams

The above table does not show the testing model, since within the framework of its construction, diagrams are not developed, but are checked (tested) for completeness and consistency.

Part of the diagrams after their construction requires development and refinement as part of the development of the next model (technological process). So, for example, should be clarified during development. in models.

4. Define the term "".