What types of lines are used in uml diagrams. Basic UML Diagrams

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

1.5.1. Usage diagram

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

The usage diagram is designed to answer the main modeling question: what does the system do in the outside world?

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

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

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

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

1.5.2. Class diagram

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

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

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

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

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

1.5.3. Machine diagram

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

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

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

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

1.5.4. Activity diagram

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

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

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

1.5.5. Sequence diagram

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

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

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

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

The time axis can be directed horizontally, in which case time is considered to flow from left to right.

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

1.5.6. Communication diagram

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

In fact, this is the same description of the sequence of message exchange of interacting instances of classifiers, only expressed by other graphical means. Moreover, most tools can automatically convert sequence diagrams to communication diagrams and vice versa.

Thus, in the communication diagram, as well as in the sequence diagram, one main type of entity is used - instances of interacting classifiers 1 and one type of relationship - connections 2.

However, here the emphasis is not on time, but on the structure of connections between specific instances.

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

1.5.7. Component Diagram Component Diagram

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

  • The main type of entities in a component diagram are the components themselves 1, as well as interfaces 2, through which the relationship between the components is indicated. The following relationships apply in a component diagram:
  • implementations between components and interfaces (a component implements an interface);

dependencies between components and interfaces (the component uses the interface) 3.

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

1.5.8. Placement diagram Placement diagram

(deployment diagram), along with displaying the composition and connections of system elements, shows how they are physically located on computing resources at runtime.

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

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 Denotes the actions performed by the system (may include possible options) leading to the results observed 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, they can be turned into substates, and the overall behavior can be transferred 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 benefits 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 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 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 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.

Final state ( final state) means that 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, 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 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 different states require different ways of reacting 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. Figure 10.2 shows the state with internal symbol activities and help system events, which you can observe in the text fields of the 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 when you need to add states. 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.

Annotation: The subject of this course is The UML - the Unified Modeling Language. The previous lecture talked about what UML is, its history, purpose, ways of using the language, the structure of its definition, terminology and notation. It has been noted that a UML model is a set of diagrams. In this lecture we will consider the following questions: why are several types of diagrams needed; types of diagrams; OOP and diagramming sequence

Before we move on to discussing the main material of this lecture, let's talk about why we need to build any diagrams at all. The development of a model of any system (not just software) always precedes its creation or update. This is necessary at least in order to more clearly imagine the problem being solved. Well-thought-out models are very important both for interaction within the development team and for mutual understanding with the customer. Ultimately, this ensures that the design is "architecturally consistent" before it is implemented in code.

We build models of complex systems because we cannot describe them completely, “take a glance at them.” Therefore, we highlight only the properties of the system that are essential for a specific task and build its model that displays these properties. The method of object-oriented analysis allows us to describe real complex systems in the most adequate way. But as the complexity of systems increases, the need for good modeling technology arises. As we already said in the previous lecture, a unified modeling language(Unified Modeling Language, UML), which is a graphical language for specifying, visualizing, designing, and documenting systems. Using UML, you can develop a detailed model of the system being created, reflecting not only its concept, but also specific features of its implementation. Within the UML model, all ideas about the system are recorded in the form of special graphical structures called diagrams.

Note. We will consider not all, but only some of the types of diagrams. For example, the component diagram is not covered in this lecture, which is only a brief overview of diagram types. The number of diagram types for a specific application model is not limited in any way. For simple applications there is no need to build diagrams of all types without exception. Some of them may simply be missing, and this fact will not be considered an error. It is important to understand that the availability of certain types of diagrams depends on the specifics of a particular project. Information about other types of diagrams (not discussed here) can be found in the UML standard.

Why you need several types of diagrams

First, let's define the terminology. In the introduction to this lecture we have repeatedly used the concepts of system, model and diagram. The author is confident that each of us intuitively understands the meaning of these concepts, but to make it completely clear, let’s look at the glossary again and read the following:

System- a set of interconnected controlled subsystems united by a common purpose of operation.

Yes, not very informative. What then is a subsystem? To clarify the situation, let's turn to the classics:

System refers to a set of subsystems organized to achieve a specific goal and described using a set of models, possibly from different points of view.

Well, there's nothing you can do, you'll have to look for a definition of a subsystem. It also says there that subsystem is a collection of elements, some of which specify the behavior of other elements. Ian Sommerville explains this concept this way:

Subsystem is a system whose functioning does not depend on the services of other subsystems. The software system is structured as a collection of relatively independent subsystems. The interactions between subsystems are also defined.

It’s also not very clear, but it’s better. Speaking in “human” language, the system is represented as a set of simpler entities that are relatively self-sufficient. This can be compared to how, in the process of developing a program, we build a graphical interface from standard “cubes” - visual components, or how the program text itself is also divided into modules that contain subroutines, united by functionality, and they can be reused, in the following programs.

We understand the concept of a system. During the design process, the system is considered from different points of view with the help of models, the various representations of which appear in the form of diagrams. Again, the reader may have questions about the meaning of the concepts models And diagrams. We think it’s a beautiful, but not very clear definition models as a semantically closed abstraction of the system It’s unlikely to clarify the situation, so we’ll try to explain “in our own words.”

Model- this is a certain (material or not) object that displays only the most significant characteristics of the system for a given task. Models are different - material and intangible, artificial and natural, decorative and mathematical...

Let's give a few examples. The plastic toy cars familiar to all of us, with which we played with such excitement in childhood, are nothing more than material artificial decorative model of a real car. Of course, such a “car” does not have an engine, we do not fill its tank with gasoline, and the gearbox does not work (indeed, there is no gearbox at all), but as a model this toy completely fulfills its functions: it gives the child an idea of ​​the car, since it displays its characteristic features are the presence of four wheels, a body, doors, windows, ability to drive, etc.

In medical research, animal testing often precedes human clinical trials. In this case, the animal acts as material natural human models.

The equation depicted above is also a model, but it is a mathematical model, and it describes the movement of a material point under the influence of gravity.

All that remains is to say what a diagram is. Diagram is a graphical representation of many elements. Typically depicted as a graph with vertices (entities) and edges (relationships). There are many examples of diagrams. This is a block diagram familiar to us all from school years, and installation diagrams for various equipment, which we can see in user manuals, and a tree of files and directories on the disk, which we can see by running the tree command in the Windows console, and much, much more other. In everyday life, diagrams surround us on all sides, because we perceive drawings more easily than text...

But let's get back to software design (and more). In this industry with Diagrams can be used to visualize a system from different perspectives. One of the diagrams, for example, can describe the user’s interaction with the system, another can describe the change in the states of the system during its operation, the third can describe the interaction of system elements with each other, etc. A complex system can and should be represented as a set of small and almost independent models - diagrams, and none of them is sufficient to describe the system and get a complete picture of it, since each of them focuses on a specific aspect of the system’s functioning and expresses a different level of abstraction. In other words, each model corresponds to a certain, particular point of view on the designed system.

Despite the fact that in the previous paragraph we treated the concept of a model very freely, it should be understood that in the context of the above definitions no individual diagram is a model. Diagrams are only a means of visualizing a model, and the two concepts must be distinguished. Only a set of diagrams makes up a system model and describes it most fully, but not just one diagram taken out of context.

Types of charts

UML 1.5 defined twelve chart types, divided into three groups:

  • four types of diagrams represent the static structure of the application;
  • five represent behavioral aspects of the system;
  • three represent the physical aspects of the system's operation (implementation diagrams).

The current version of UML 2.1 has not made too many changes. The diagrams have changed slightly in appearance (frames and other visual improvements have appeared), the notation has been slightly improved, and some diagrams have received new names.

However, the exact number canonical diagrams for us it is absolutely unimportant, since we will consider not all of them, but only some - for the reason that the number of diagram types for a specific model of a specific application is not strictly fixed. For simple applications there is no need to build every single diagram. For example, for a local application it is not necessary to build a deployment diagram. It is important to understand that the list of diagrams depends on the specifics of the project being developed and is determined by the developer himself. If the curious reader still wants to know about all the UML diagrams, we will refer him to the UML standard (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Let us remind you that the purpose of this course is not to describe absolutely all the capabilities of UML, but only to introduce this language and give an initial idea of ​​​​this technology.

So, we will briefly look at such types of diagrams as:

  • use case diagram;
  • class diagram;
  • object diagram;
  • sequence diagram;
  • interaction diagram;
  • state diagram;
  • activity diagram;
  • deployment diagram.

We will talk about some of these diagrams in more detail in future lectures. For now, we will not focus on the details, but will set ourselves the goal of teaching the reader to at least visually distinguish between the types of diagrams and to give an initial idea of ​​the purpose of the main types of diagrams. So, let's begin.

Use case diagram

Any (including software) systems are designed taking into account the fact that during their operation they will be used by people and/or interact with other systems. The entities with which the system interacts during its operation are called actors, and each actor expects the system to behave in a strictly defined, predictable manner. Let's try to give a more strict definition of an ector. To do this, we will use a wonderful visual dictionary for UML Zicom Mentor:

Ector (actor)- this is a set of logically related roles performed when interacting with precedents or entities (system, subsystem or class). An actor can be a person or another system, subsystem or class that represents something outside the entity.

Graphically, the ector is depicted either " little man", similar to those that we drew as children, depicting members of our family, or class symbol with corresponding stereotype, as it shown on the picture. Both forms of representation have the same meaning and can be used in diagrams. The “stereotyped” form is more often used to represent system actors or in cases where an actor has properties and they need to be displayed (Fig. 2.1).

An attentive reader may immediately ask: why an actor and not an actor? We agree, the word “ektor” is a little harsh on the ears of Russian people. The reason why we say this is simple - ector is derived from the word action, which translated means action. The literal translation of the word “ector” is actor- too long and inconvenient to use. Therefore, we will continue to speak this way.


Rice. 2.1.

The same attentive reader might have noticed the word “precedent” flashing through the ector’s definition. What is it? This question will interest us even more if we remember that we are now talking about use case diagram. So,

Use-case- description of a separate aspect of system behavior from the user’s point of view (Butch).

The definition is quite clear and comprehensive, but it can be further clarified using the same Zicom Mentor"om:

Use case- a description of a set of sequential events (including options) performed by the system that lead to the result observed by the actor. A use case represents the behavior of an entity, describing the interaction between actors and the system. A use case does not show “how” a certain result is achieved, only “what” is accomplished.

Precedents are designated in a very simple way - in the form of an ellipse, inside of which its name is indicated. Use cases and actors are connected using lines. Often a figure is drawn at one end of the line. 2.3

  • formation of general requirements for the behavior of the designed system;
  • development of a conceptual model of the system for its subsequent detailing;
  • preparation of documentation for interaction with customers and system users.

    • 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 allows software developers to agree on graphical notations to represent common concepts and focus on design and development.

    • 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

    Structure diagrams

    1. Class diagram is a key element in object-oriented modeling. Using this diagram (actually, through classes, their attributes, methods and dependencies between classes) describes the domain model and the structure of the modeled system.
    2. 1.5.7. Component Diagram 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 models the deployment of software components ( 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. Communication diagram 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.(in earlier versions
    5. Sequence diagram cooperation diagram
    6. ) shows the interactions between the parts of the composite structure and the roles of cooperation. The diagram explicitly indicates the relationships between elements (objects). used to visualize the sequence of object interactions. Shows the life cycle of a given object and the interaction of actors (actors) within a certain use case, the sequence of messages that they exchange.
    7. Interaction overview diagram includes part of the sequence diagram and control flow design. Helps to consider the interaction of objects from different points of view.

    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.

    Currently, UML is a standard notation for visual modeling of software systems, adopted by the Object Managing Group (OMG) consortium in the fall of 1997, which is supported by many object-oriented CASE products.

    The UML standard offers the following set of diagrams for modeling:

    · use case diagram – for modeling the business processes of an organization or enterprise and determining the requirements for the information system being created;

    · class diagram – for modeling the static structure of system classes and connections between them;

    · behavior diagrams of the system;

    · collaboration diagram – for modeling the process of messaging between objects within one use case;

    · statechart diagram – for modeling the behavior of system objects during the transition from one state to another;

    · activity diagram – for modeling the behavior of the system within the framework of various use cases, or modeling activities;

    implementation diagrams:

    · component diagrams – for modeling the hierarchy of components (subsystems) of an information system;

    · deployment diagram – for modeling the physical architecture of the designed information system.

    In Fig. 1.1 presents an integrated model of an information system, including the main diagrams that should be developed in this course project.

    Rice. 1. Integrated model of an information system in UML notation

    4.2. Use case diagram

    A use case is a sequence of actions performed by the system in response to an event initiated by some external object (actor). A use case describes a typical interaction between a user and a system. In the simplest case, the use case is determined in the process of discussing with the user the functions that he would like to implement in this information system. In UML, a use case is depicted as follows:

    Fig.2. Use case

    An actor is the role that a user plays in relation to the system. Actors represent roles, not specific people or job titles. Although they are depicted as stylized human figures in use case diagrams, an actor can also be an external information system that needs some information from that system. Actors should only be shown on the diagram if they actually need some use cases. In UML, actors are represented as shapes:



    Fig.3. Character (actor)

    Actors are divided into three main types:

    · users;

    · systems;

    · other systems interacting with this one;

    Time becomes an actor if the launch of any events in the system depends on it.

    4.2.1. Relationships between use cases and actors

    In UML, use case diagrams support several types of relationships between diagram elements:

    · communication

    inclusion (include),

    · extension (extend),

    · generalization.

    communication link is the relationship between a use case and an actor. In UML, communication relationships are shown using a unidirectional association (solid line).

    Fig.4. Communication link example

    Enable connection used in situations where there is some piece of system behavior that is repeated in more than one use case. These connections are typically used to model a reusable function.

    Expansion communication used to describe changes in the normal behavior of a system. It allows one use case to use the functionality of another use case when needed.

    Fig.5. Example of inclusion and extension relationship

    Generalization connection shows that several actors or classes have common properties.

    Fig.6. Generalization link example

    4.3.



    Interaction diagrams describe the behavior of interacting groups of objects. Typically, an interaction diagram covers the behavior of objects within only one use case. Such a diagram displays a number of objects and the messages that they exchange with each other.

    Message is the means by which a sending object requests a recipient object to perform one of its operations.

    Informational message is a message that provides the recipient object with some information to update its state.

    Request message (interrogative) is a message requesting the release of some information about the recipient object.

    Imperative message is a message that requests the recipient object to perform some action.

    There are two types of interaction diagrams: sequence diagrams and collaboration diagrams.

    4.3.1. Sequence diagrams

    Sequence diagram reflects the flow of events occurring within a single use case.

    All actors (actors, classes or objects) involved in a given scenario (use case) are shown at the top of the diagram. The arrows correspond to messages passed between an actor and an object or between objects to perform required functions.

    In a sequence diagram, an object is depicted as a rectangle with a dotted vertical line drawn down from it. This line is called lifeline of the object . It represents a fragment of the life cycle of an object in the process of interaction.

    Each message is represented as an arrow between the life lines of two objects. Messages appear in the order they appear on the page from top to bottom. Each message is tagged with at least a message name. If desired, you can also add arguments and some control information. You can show self-delegation - a message that an object sends to itself, with the message arrow pointing to the same life line.

    Rice. 7. Example of a sequence diagram

    4.3.2. Collaboration diagram

    Cooperation diagrams display the flow of events within a specific scenario (use case). Messages are ordered by time, although collaboration diagrams focus more on the connections between objects. A collaboration diagram presents all the information that is present in a sequence diagram, but a collaboration diagram describes the flow of events differently. It makes it easier to understand the connections that exist between objects.

    In a collaboration diagram, just like in a sequence diagram, arrows represent messages exchanged within a given use case. Their time sequence is indicated by numbering the messages.

    Rice. 8. Example of a cooperation diagram

    4.4. Class diagram

    4.4.1. General information

    Class diagram defines the types of classes of the system and various kinds of static connections that exist between them. Class diagrams also depict the attributes of classes, the operations of classes, and the restrictions that are imposed on the relationships between classes.

    A class diagram in the UML language is a graph, the nodes of which are elements of the static structure of the project (classes, interfaces), and the arcs are the relationships between nodes (associations, inheritance, dependencies).

    The class diagram depicts the following elements:

    · Package - a set of model elements logically related to each other;

    · Class (class) - description of the common properties of a group of similar objects;

    · Interface - an abstract class that specifies a set of operations that an object of an arbitrary class associated with a given interface provides to other objects.

    4.4.2. Class

    Class is a group of entities (objects) that have similar properties, namely, data and behavior. An individual representative of a class is called an object of the class or simply an object.

    The behavior of an object in UML refers to any rules for the interaction of an object with the outside world and with the data of the object itself.

    In the diagrams, the class is depicted as a rectangle with a solid border, divided by horizontal lines into 3 sections:

    The top section (name section) contains the class name and other general properties (in particular, the stereotype).

    The middle section contains a list of attributes

    At the bottom is a list of class operations that reflect its behavior (actions performed by the class).

    Any of the attribute and operation sections may not be displayed (or both at once). For a missing section, you do not need to draw a dividing line or in any way indicate the presence or absence of elements in it.

    Additional sections, such as exceptions, may be introduced at the discretion of the specific implementation.

    Rice. 9. Example of a class diagram

    4.4.2.1.Class stereotypes

    Class stereotypes are a mechanism for dividing classes into categories.

    The UML defines three main class stereotypes:

    Boundary (border);

    Entity (entity);

    Control.

    4.4.2.2.Boundary classes

    Boundary classes are those classes that are located on the boundary of the system and the entire environment. These include displays, reports, interfaces with hardware (such as printers or scanners), and interfaces with other systems.

    To find boundary classes, you need to examine use case diagrams. Every interaction between an actor and a use case must be associated with at least one boundary class. It is this class that allows an actor to interact with the system.

    4.4.2.3.Entity classes

    Entity classes contain stored information. They have the greatest meaning for the user, and therefore their names often use terms from the subject area. Typically, a table is created in the database for each entity class.

    4.4.2.4.Control classes

    Control classes are responsible for coordinating the actions of other classes. Typically, each use case has one control class that controls the sequence of events for that use case. The manager class is responsible for coordination, but does not provide any functionality itself, since the other classes do not send many messages to it. Instead, he sends many messages himself. A manager class simply delegates responsibility to other classes, which is why it is often called a manager class.

    There may be other control classes in the system that are common to multiple use cases. For example, there may be a SecurityManager class (security manager) responsible for monitoring security-related events. The TransactionManager class is responsible for coordinating messages related to database transactions. There may be other managers to handle other elements of the system's operation, such as resource sharing, distributed data processing, or error handling.

    In addition to the stereotypes mentioned above, you can create your own.

    4.4.2.5.Attributes

    An attribute is an element of information associated with a class. Attributes store encapsulated class data.

    Because attributes are contained within a class, they are hidden from other classes. Because of this, you may need to specify which classes have the right to read and change attributes. This property is called attribute visibility.

    The attribute can have four possible values ​​for this parameter:

    Public (general, open). This visibility value assumes that the attribute will be visible to all other classes. Any class can view or change the value of an attribute. According to UML notation, a common attribute is preceded by a "+" sign.

    Private (closed, secret). The corresponding attribute is not visible to any other class. A private attribute is denoted by a “–” sign according to UML notation.

    Protected (protected). This attribute is available only to the class itself and its descendants. The UML notation for a protected attribute is the "#" sign.

    Package or Implementation (package). Assumes that the attribute is shared, but only within the scope of its package. This type of visibility is not indicated by any special icon.

    With the help of closedness or security, it is possible to avoid a situation where the value of an attribute is changed by all classes of the system. Instead, the logic for changing the attribute will be contained in the same class as the attribute itself. The visibility settings you set will affect the generated code.

    4.4.2.6.Operations

    Operations implement behavior associated with a class. An operation has three parts: a name, parameters, and a return type.

    Parameters are the arguments received by the operation as input. The return type refers to the result of the operation.

    A class diagram can show both operation names and operation names along with their parameters and return type. To reduce the load on the diagram, it is useful to show only the names of operations on some of them, and their full signature on others.

    In UML, operations have the following notation:

    Operation Name (argument: argument datatype, argument2:argument2 datatype,...): return type

    There are four different types of operations to consider:

    Implementation operations;

    Management Operations;

    Access operations;

    Auxiliary operations.

    Implementation Operations

    Implementor operations implement certain business functions. Such operations can be found by examining interaction diagrams. This type of diagram focuses on business functions, and each message in the diagram can likely be mapped to an implementation activity.

    Each implementation operation must be easily traceable to the corresponding requirement. This is achieved at various stages of the simulation. The activity is derived from the message in the interaction diagram, the messages come from a detailed description of the flow of events that is created based on the use case, and the latter is created based on the requirements. The ability to trace this entire chain allows you to ensure that every requirement is implemented in code, and every piece of code implements some requirement.

    Control Operations

    Manager operations control the creation and destruction of objects. Class constructors and destructors fall into this category.

    Access Operations

    Attributes are usually private or protected. However, other classes sometimes need to view or change their values. There are access operations for this purpose. This approach makes it possible to securely encapsulate attributes within a class, protecting them from other classes, but still allowing controlled access to them. It is standard to create Get and Set operations for each class attribute.

    Auxiliary Operations

    Helper operations are those operations of a class that are necessary for it to perform its responsibilities, but about which other classes should not know anything. These are private and protected class operations.

    To identify transactions, follow these steps:

    1. Learn sequence diagrams and cooperative diagrams. Most of the messages in these diagrams are implementation operations. Reflective messages will be auxiliary operations.

    2. Consider control operations. You may need to add constructors and destructors.

    3. Consider access operations. For each class attribute that other classes will need to work with, you need to create Get and Set operations.

    4.4.2.7.Connections

    A relationship represents a semantic relationship between classes. It gives a class the ability to learn about the attributes, operations, and relationships of another class. In other words, for one class to send a message to another in a sequence diagram or cooperative diagram, there must be a relationship between them.

    There are four types of relationships that can be established between classes: associations, dependencies, aggregations, and generalizations.

    Communication Association

    Association is a semantic connection between classes. They are drawn on the class diagram as an ordinary line.

    Rice. 10. Communication Association

    Associations can be bidirectional, as in the example, or unidirectional. In UML, bidirectional associations are drawn as a simple line without arrows or with arrows on both sides. A unidirectional association has only one arrow showing its direction.

    The direction of association can be determined by examining sequence diagrams and cooperative diagrams. If all messages on them are sent by only one class and received only by another class, but not vice versa, there is a one-way communication between these classes. If at least one message is sent in the opposite direction, the association must be bidirectional.

    Associations can be reflexive. Reflexive association involves one instance of a class interacting with other instances of the same class.

    Communication addiction

    Dependency relationships also reflect relationships between classes, but they are always unidirectional and show that one class depends on definitions made in another. For example, class A uses methods of class B. Then when class B changes, it is necessary to make corresponding changes in class A.

    A dependency is represented by a dotted line drawn between two diagram elements, and the element anchored at the end of the arrow is said to depend on the element anchored at the beginning of that arrow.

    Rice. 11. Communication addiction

    When generating code for these classes, no new attributes will be added to them. However, language-specific operators will be created to support communication.

    Communication aggregation

    Aggregations are a tighter form of association. Aggregation is a connection between the whole and its part. For example, you might have a class called Car, as well as classes like Engine, Tires, and classes for other parts of the car. As a result, an object of the Car class will consist of an object of the Engine class, four Tire objects, etc. Aggregations are visualized as a line with a diamond near the class, which is an integer:

    Rice. 11. Communication aggregation

    In addition to simple aggregation, UML introduces a stronger type of aggregation called composition. According to composition, an object-part can belong only to a single whole, and, in addition, as a rule, the life cycle of the parts coincides with the cycle of the whole: they live and die with it. Any deletion of the whole applies to its parts.

    This cascading deletion is often considered as part of the definition of aggregation, but it is always implied when the role multiplicity is 1..1; for example, if it is necessary to delete a Customer, then this deletion must also apply to Orders (and, in turn, to Order Lines).