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

Action plan

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

After reading the other sections (Example, Application), you can try your hand at creating state diagrams yourself.

Notes (description)

Here is the basic character set state diagrams, necessary 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		Identifies actions performed by the system (may include possible options), leading to results observable by the actors.
State activity state		A difficult step in a precedent can be represented by another precedent. In UML terms, we say that the first use case includes the second.
Final state		Allows you to define the boundaries of systems or subsystems.
Internal activities		The case where states can react to events without making a transition, in which case the event, protection and activity are placed inside the state rectangle.
Input activity		The input activity is executed whenever you enter a state
Output activity		Exit activity – Executes 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, and transfer the general behavior to a superstate.
Parallel states		States can be split into multiple parallel states that run simultaneously.

How to use creativity techniques

UML statecharts 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) do an excellent job of describing the behavior of multiple objects in a single use case, and UML activity diagrams are good for showing the basic sequence of actions of several objects in several use cases.

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

If you use state diagrams, don't try to draw them for every class of the system. This approach is often used for the purpose of formally strict completeness, but it is almost always a waste of effort. Use statecharts only for classes that exhibit interesting behavior where drawing a statechart helps you understand how things happen.

Many experts believe that The UI editor and control objects have functionality that is useful when displayed using a state diagram.

How to learn

Here we have tried to provide as simple a way as possible to learn UML state diagrams.

Like many other languages, it uses a set of symbols for description. The meaning of these signs 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 basic essence.

Next, we would recommend going to the “Examples” section state diagrams to try your hand at reading different diagrams. Then it is worth studying the “Application” section, since, although the number of diagram types in UML is small, you can get the maximum benefit from their use only if you use the corresponding diagrams for their intended purpose.

Usage example

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

Whenever finite state machines are written about, examples inevitably include cruise control systems or vending machines.
We decided to use a secret control panel controller in a Gothic castle. In this castle we want to hide our treasures so that they are difficult to find. In order to access the safe's lock, we must remove the strategic candle from the candelabra, but the lock will only appear 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 does not pay attention to this precaution, then we will unleash a disgusting monster that will swallow the thief.

In Fig. 10.1 shown state diagram a controller class that manages my fancy security system. The state diagram begins with the state of the controller object being created: state Wait. This is indicated in the diagram by 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, Lock and Open. The diagram also shows the rules by which the controller transitions from one state to another. These rules are presented in the form of transitions - lines connecting states.

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

The guard, if specified, is a logical condition that must be satisfied for the transition to take place. Activity is some behavior of the system during a transition. This 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 shields means that the transition is always made if a trigger event occurs. The trigger ID is rarely missing, but it does happen. This means that the transition occurs immediately, which can be observed mainly in active states.

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

Final state ( final state) means the state machine has finished running, causing the controller object to be deleted. So for those who were careless enough to fall into the trap, since the controller object ceases to exist, we are forced to put the rabbit back in the cage, clean 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 this 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 the combination of all the data contained in the objects' fields. However, a state in a state machine diagram is a more abstract concept of state; the point is that the various states imply various ways reactions to events.

Internal Activities in a Statechart

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

In Fig. 10.2 shows the state with internal symbol activities and help system events that you can observe in text fields editor UI. Internal 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.

In Fig. 10.2 also shows special activities: input and output activities. Input activity executed whenever you enter a state; output activity- whenever you leave the state. However, internal activities are not initiated input and output activities; this is the difference between internal activities andself-transitions .

Activity states in a state diagram

In the states we have 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 a symbol do/; hence the term do-activity (be active). After the search is completed, transitions are performed without activity, such as showing new equipment (Display New Hardware). If a cancellation event occurs during an activity ( cancel), That do-activity just interrupts and we return to the state Update Hardware Window.

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

IN UML 1 ordinary activities were designated 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, they can be turned into substates, and the overall behavior can be transferred to a superstate, as shown in Fig. 10.4. Without a superstate, we would have to draw a transition cancel(cancel) for all three states within a state Enter Connection Details.

Parallel states

States can be split into multiple parallel states that run simultaneously. In Fig. Figure 10.5 shows a simple alarm clock that can turn on either a CD or radio and show either the current time or the alarm time.

The CD/Radio and Current Time/Alarm Time options are parallel. If you wanted to represent this using a non-parallel state diagram, you would end up with a messy diagram where states need to be added. Separating the two areas of behavior into two state diagrams makes it much clearer.

Rice. 10.5 also includes state of prehistory(history pseudostate). This means that when the clock is turned on, the radio/CD option goes into the state the clock was in when it was turned off. The arrow coming out of the prehistory shows what state existed initially when there was no prehistory.

Implementing Statecharts

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

Although this method is straightforward, 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 a state diagram has its own subclass of state. The controller has methods for each event that simply forward to the state class. The state diagram shown in Fig. 10.1 could be implemented using the classes presented in Fig. 10.7.

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

So, the diagram in Fig. 10.1 can be presented in the form of a table. 10.1.
We then build an interpreter that uses the runtime state table, or a code generator that generates classes from that table.

Obviously, most of the work on the state table is done once, but it can then be used whenever a state problem needs to be solved. The runtime 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 needs to be written is quite small.

The implementations shown are almost minimal, but they give an idea of ​​how to use state diagrams. In each case, the implementation of state models results in a rather stereotypical program, so it is usually better to resort to some form of code generation to achieve this.

Subscribe to the site's news; you can find the subscription form in the right column of the site.

If you want to learn how to work as a freelancer professionally, we invite you to the “” course.

        Unified Modeling Language (UML) is a language for specification, visualization, design and documentation 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, which:

• 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

        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 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 annotation elements - 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.

        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. It could be a person technical device, 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 the request, it must return to the initial state to be ready for the following requests

        Use cases can be used both to specify external requirements for the system being designed, and to specify the functional behavior of already 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 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.

        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 various types structural relations. 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, the class is depicted as a rectangle, which can additionally be divided 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.

        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.

        Actually this type diagrams can also be used to reflect the states of the modeled object, however, the main purpose of an 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 state diagrams, 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 of significant importance 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 point for sequence diagrams is the dynamics of interaction of objects 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. The interactions of objects are implemented through messages that are sent by one object to another. Messages are displayed 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 interactions of the “earlier-later” type.

Collaboration diagram

        main feature cooperation diagrams 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.

        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 can be depicted - message flows. 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 connections 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.

        A complete software system project is a set of models of logical and physical levels, which must be consistent with each other. The UML language 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 general structure source code software system;
• specifications of the executable version of the software system;
• ensuring reuse of individual fragments program code;
• 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. For graphical representation of the component it is used special character- a rectangle with two smaller rectangles inserted on the left. Inside the large rectangle is written 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.

        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 you are developing a program that runs locally on the user's computer and does not use peripheral devices and resources, 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 graphic images 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 has the following appearance (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 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. The button assignments can be learned from the tooltips that appear after hovering the mouse pointer 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 of visual means in the UML language 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 describes the new era of software development, its impact on 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, graphic elements and language diagrams.
  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)

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 modeling business processes, system design and mapping organizational structures. UML enables software developers to agree on graphical notations for representing general concepts

and focus on design and development.

• Benefits of UML
• UML uses graphical notations for the elements of the system being modeled, and UML diagrams are fairly easy to understand;
• UML makes it possible to describe systems from almost all possible points 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 enter additional text and graphic types, which makes it possible to use UML not only in the IT field.

UML Diagram Types

• There are 14 types of diagrams in UML. They can be divided into 2 categories: structural
• , representing information structure; behavioral , representing the behavior of the system and various aspects of interactions. A separate subtype of behavior diagrams are considered.

interaction diagrams
Hierarchy of UML diagram types,

represented by a class diagram

1. Structure diagrams Class diagram is a key element in object-oriented modeling. Using this diagram (actually, through classes , their, attributes methods
2. and dependencies between classes) describes the domain model and the structure of the modeled system. displays the breakdown of 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 slice of the simulated system at a given point in time. It represents class instances (objects), their state (current attribute values), and the relationships between them.
4. Composite structure diagram demonstrates the internal structure of classes and, where possible, the interactions between elements of this structure.
5. Package diagram shows packages and 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 simulates deployment software components ov ( artifacts) on computing resources/hardware components ( nodes).
7. Profile diagram describes an extension mechanism that allows UML to be adapted to a variety of subject areas and industries.

Example UML Class Diagram

Behavior diagrams

1. Activity diagram shows actions ( actions) of which some activity consists ( activity). Activity diagrams are used to model business processes, technological processes, sequential and parallel computing.
2. Use Case Diagram(or use case diagram) describes the relationship between actors (actors) and use cases of the modeled system (its capabilities).
3. The main purpose of the diagram is to be a universal tool for customers, developers and end users to jointly discuss the system - its capabilities and behavior. State diagram
4. depicts the dynamic behavior of an entity, showing how this entity, depending on its current state, reacts to various events. This is essentially a state diagram from atom theory. Communication diagram (V earlier versions
5. cooperation diagram) shows the interactions between the parts of the composite structure and the roles of cooperation. The diagram explicitly indicates the relationships between elements (objects).
6. Sequence diagram includes part of the sequence diagram and control flow design. Helps to consider the interaction of objects from different points of view.
7. Timing diagram- a separate subtype of interaction diagrams specializing in timing. Diagrams of this type are used to study the behavior of objects over a certain period of time.

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

A Brief History of UML

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

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

UML is a language

Any language consists of a vocabulary and rules for combining words to create meaningful constructions. This is, in particular, how programming languages ​​are structured, such as UML. Its distinctive feature is that the language dictionary is formed by graphic elements. Each graphic symbol has a specific semantics associated with it, so a model created by one developer can be clearly understood by another, as well as by a software tool that interprets UML. From here, in particular, it follows that a software model presented in UML can be automatically translated into an OO programming language (such as Java, C++, VisualBasic), that is, if there is a good visual modeling tool that supports UML, having built the model , we will also receive a sample program code corresponding to this model.

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

UML Dictionary

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

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

Relationship show various connections between entities. The following types of relationships are defined in UML:

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

Diagrams. UML provides the following diagrams:

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

Model Control View. Packages.

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

What UML provides.

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

And the last thing...

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

What is UML?

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

As Wikipedia says

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

Application

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

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

You can go into as much detail as necessary. All designations are indicated here: "PlantUML - Class Diagram". In addition, there is nothing supernatural in drawing such a diagram, and when working on your tasks, you can quickly draw it by hand. This will develop skills in thinking through application architecture and help identify shortcomings in the class structure of the application. early stage, not when you've already spent the day implementing the wrong model. I think that's a good reason to give it a try?)

Automation

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

Conclusion