General characteristics of the UML language. Basic diagrams of the UML language Line types are used in uml diagrams

21.06.2021

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

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

Use case diagram (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 (class diagram) - for modeling the static structure of the system classes and the relationships between them;

system behavior diagram (behavior diagrams);

interaction diagrams;

Sequence diagrams - for modeling the process of messaging between objects within one use case;

collaboration diagram (collaboration diagram) - for modeling the process of messaging between objects within the same 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 diagram (implementation diagrams):

Component diagrams (component diagrams) - for modeling the hierarchy of components (subsystems) of an information system;

deployment diagram (deployment diagram) - for modeling the physical architecture of the designed information system.

On fig. 1.1 presents an integrated model of the information system, including the main diagrams to be developed in this course project.

Rice. 1. An integrated model of an information system in the notation of the UML language

4.2. Use case diagram

A use case is a sequence of actions performed by the system in response to an event triggered 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 a 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 the system. You should only show actors in a diagram when they really 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 triggering 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 (communication),

Inclusion (include),

extension (extend),

generalization.

communication communication is the relationship between the use case and the actor. In UML, communication links are shown using a one-way association (solid line).

Fig.4. Communication link example

Inclusion connection used in situations where there is some piece of system behavior that is repeated in more than one use case. With the help of such links, a reusable function is usually modeled.

Extension connection 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. An example of an inclusion and extension relationship

Communication generalization indicates that several actors or classes have common properties.

Fig.6. An example of a generalization relationship

4.3.

Interaction diagrams describe the behavior of interacting groups of objects. Typically, an interaction diagram only covers the behavior of objects within a single 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 the sender object requests the receiver object to perform one of its operations.

Information (informative) message is a message that provides the receiving object with some information to update its state.

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

Imperative message is a message that asks the receiver 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. Arrows correspond to messages passed between an actor and an object, or between objects to perform the required functions.

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

Each message is represented as an arrow between the lifelines of two objects. Messages appear in the order they appear on the page from top to bottom. Each message is tagged with at least the message name. Optionally, 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 lifeline.

Rice. 7. Sequence Diagram Example

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 relationships between objects. A collaboration diagram shows all the information that a sequence diagram has, but a collaboration diagram describes the flow of events in a different way. From it it is easier to understand the connections that exist between objects.

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

Rice. 8. An example of a cooperation diagram

4.4. class diagram

4.4.1. General information

class diagram defines the types of system classes and various kinds of static links that exist between them. Class diagrams also show class attributes, class operations, and constraints that are placed on relationships between classes.

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

The class diagram shows the following elements:

· Package (package) - a set of elements of the model, logically related to each other;

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

· Interface (interface) - an abstract class that defines 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 member 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 diagrams, a class is depicted as a rectangle with a solid border, divided by horizontal lines into 3 sections:

The top section (the name section) contains the name of the class 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 shown (or both). For the missing section, you do not need to draw a dividing line and somehow indicate the presence or absence of elements in it.

Additional sections, such as Exceptions, may be introduced at the discretion of a particular implementation.

Rice. 9. Class Diagram Example

4.4.2.1.Class stereotypes

Class stereotyping is a mechanism for classifying classes into categories.

The UML defines three main class stereotypes:

Boundary (border);

Entity (entity);

Control (management).

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 are displays, reports, interfaces with hardware (such as printers or scanners), and interfaces with other systems.

To find boundary classes, you need to explore use case diagrams. Every interaction between an actor and a use case must have at least one boundary class. It is this class that allows the 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. Usually, for each entity class, a table is created in the database.

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 control class is responsible for coordination, but does not carry any functionality in itself, since the other classes do not send it a large number of messages. Instead, he himself sends a lot of messages. The manager class simply delegates responsibility to other classes, which is why it is often referred to as the manager class.

There may be other control classes in the system that are common to several use cases. For example, there might be a SecurityManager class responsible for monitoring security-related events. The TransactionManager class handles the coordination of messages related to database transactions. There may be other managers to deal with 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 a piece of information associated with a class. Attributes store encapsulated class data.

Because the attributes are contained within the class, they are hidden from other classes. Because of this, it may be necessary to specify which classes have the right to read and modify 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. In accordance with 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 in accordance with UML notation.

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

Package or Implementation (batch). Assume that the given attribute is shared, but only within 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 the situation when the attribute value is changed by all classes of the system. Instead, the attribute modification logic will be wrapped in the same class as the attribute itself. The visibility options you set will affect the generated code.

4.4.2.6.Operations

Operations implement class-related behavior. An operation has three parts - a name, parameters, and a return type.

Parameters are the arguments that the operation receives as input. The return type refers to the result of the action of the operation.

A class diagram can show both the names of operations and the names of operations 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 data type, argument2: argument2 data type,...): return type

There are four different types of operations to consider:

Implementation operations;

Management operations;

Access operations;

Auxiliary operations.

Implementation operations

Implementor operations implement some business functions. Such operations can be found by examining interaction diagrams. Diagrams of this type focus on business functions, and each message in the diagram can most likely be associated with an implementation operation.

Each implementation operation must be easily traceable to the corresponding requirement. This is achieved at various stages of the simulation. The operation is derived from the message in the interaction diagram, the messages are derived from the detailed description of the flow of events, which is generated based on the use case, and the latter based on the requirements. Being able to trace this entire chain helps ensure that each requirement is implemented in the code, and each piece of code implements some requirement.

Management operations

Manager operations manage 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. This approach makes it possible to safely encapsulate attributes within a class, protecting them from other classes, but still allowing controlled access to them. Creating Get and Set operations (getting and changing a value) for each attribute of a class is a standard.

Auxiliary operations

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

To identify transactions, do the following:

1. Study 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 is 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 or cooperative diagram, there must be a connection between them.

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

Communication association

An association is a semantic relationship 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 the UML, bidirectional associations are drawn as a simple line with no arrows, or with arrows on both sides of the line. A unidirectional association has only one arrow showing its direction.

The direction of an 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 unidirectional 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 means that one instance of a class interacts with other instances of the same class.

Communication addiction

Dependency relationships also reflect the relationship 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 dashed line drawn between two diagram elements, and the element anchored at the end of an arrow is said to be dependent 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, the language-specific operators needed to support communication will be created.

Communication aggregation

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

Rice. 11. Communication aggregation

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

This cascading deletion is often considered part of the definition of aggregation, but it is always implied when the role multiplicity is 1..1; for example, if a Customer needs to be deleted, then that deletion must be propagated to Orders (and, in turn, Order Lines).

All UML diagrams can be conditionally 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, decision 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 intended to answer the main question of modeling: what does the system do in the outside world?

In the use diagram, two types of main entities are used: use cases 1 and actors 2, between which the following main 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, can have comments 7 . Moreover, it is strongly recommended to do this to improve the readability of the charts.

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

1.5.2. class diagram

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

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

On the class diagram, one main type of entities is used: classes 1 (including numerous special cases of classes: interfaces, primitive types, association classes, and many others), between which the following main types of relationships are established:

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

Some elements of the notation used in the class diagram are shown below. A detailed description is given in chapter 3 .

1.5.3. automaton diagram

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

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

In the automaton diagram, one main type of entities is used - states 1 , and one type of relations - transitions 2 , but for both of them a lot of varieties, special cases and additional designations are defined. To list them all in an introductory review does not make sense.

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 on the automaton diagram.

1.5.4. activity diagram

activity diagram(activity diagram) - a way to describe behavior based on the indication of control flows and data flows.

An activity diagram is another way of describing behavior that visually resembles a good old 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.

In the activity diagram, one main type of entities is used - 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 they are not really such, but are a graphical way of depicting some special cases of many-place relationships. The semantics of activity diagram elements are discussed in detail in Chapter 4. The main elements of the notation used in the activity diagram are shown below.

1.5.5. sequence diagram

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

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

In the sequence diagram, one main type of entities is used - instances of interacting classifiers 1 (mainly classes, components and actors), and one type of relationship - connections 2 through which messages are exchanged 3 . There are several ways to send messages, which in graphical notation differ in the form of an arrow corresponding to a relation.

An important aspect of the sequence diagram is the explicit display of the passage of time. Unlike other types of diagrams, except perhaps for synchronization diagrams, in a sequence diagram, not only the presence of graphic links between elements is important, but also the relative position of elements on the diagram. Namely, it is considered 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 main elements of the notation used in a sequence diagram. To designate the interacting objects themselves, the standard notation is used - a rectangle with the name of a classifier instance. The dotted line coming out of it is called the life line (lifeline) 4 . This is not a designation of a relationship in the model, but a graphical commentary intended to point the reader of the diagram in the right direction. Figures in the form of narrow strips superimposed on the life line are also not images of simulated entities. This is a graphical comment showing the length of time an object owns an execution occurrence 5 or in other words an activation of an object takes place. Compound interaction steps (combined fragment) 6 allow the sequence diagram to reflect the algorithmic aspects of the interaction protocol. See Chapter 4 for more details on sequence diagram notation.

1.5.6. Communication Diagram

Communication Diagram(communication diagram) - a way of describing behavior, semantically equivalent to a sequence diagram.

In fact, this is the same description of the message exchange sequence of interacting instances of classifiers, only expressed by other graphic 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 entities 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 relationships between specific instances.

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

1.5.7. Component Diagram

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

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

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

The figure shows the main elements of the notation used in the 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 relationships of system elements, shows how they are physically located on computing resources during execution.

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

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

11.1. Structure of the Unified Modeling Language

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

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

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

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

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

Rice. 11.1. UML structure

11.2. Semantics and Syntax of UML

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

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

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

11.3. UML notation

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

The UML defines three entity type :

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

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

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

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

Table 11.1. Essences

Type	Name	Designation	Definition (semantics)
Structural	(class)		A set of objects that share a common structure and behavior
	(object)		An abstraction of a real or imaginary entity with well-defined conceptual boundaries, individuality (identity), state and behavior. From the UML point of view, objects are class instances (entity instances)
	(actor)	Engineer path services	An entity external to the system that interacts with the system and uses its functionality to achieve certain goals or solve particular problems. Thus, an actor is an external source or receiver of information.
	(use case)		Description of the actions performed by the system, which leads to a result that is significant for the actor
	(state)		Description of the moment in the life of an entity when it satisfies some condition, performs some activity, or waits for some event to occur.
	Cooperation (collaboration)		Description of a set of instances of actors, objects and their interaction in the process of solving a certain problem
	(component)		The physical part of the system (file), including system modules that provide the implementation of a consistent set of interfaces
	(interface)	iCalculation	A set of operations that defines a service (set of services) provided by a class or component
	(node)		The physical part of the system (computer, printer, etc.) that provides resources for solving a problem
Grouping	(package)		General mechanism for grouping elements. Unlike a component, a package is a purely conceptual (abstract) concept. Special cases of a package are system and model
	(fragment)		Area of Specific Interaction of Actor and Object Instances
	(activity partition)		A group of operations (area of responsibility) performed by a single entity (actor, object, component, node, etc.)
	(interruptible activity region)		A group of operations, the normal sequence of execution of which can be interrupted as a result of an unusual situation
explanatory	Note (comment)		Element comment. Attached to the commented element with a dashed line

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

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

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

Table 11.3. Relations

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

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

- * - any number of copies, including none;

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

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

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

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

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

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

Table 11.4. Extension mechanisms

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

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


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

Rice. 11.2. Examples of standard and stereotypical class mapping

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

Table 11.5. Diagrams

Diagram			Purpose
				according to the degree of physical implementation	by displaying dynamics	by displayed aspect
(use case)			Displays system functions, interaction between actors and functions	logical	static	functional
(class)			Displays a set of classes, interfaces and relationships between them	Boolean or physical	static	Functional information
(package)			Displays a set of packages and their relationships	Boolean or physical	static	Component
behavior (behavior)	(state machine)		Displays entity states and transitions between them during its life cycle	logical	Dynamic	behavioral
	(activity)		Displays business processes in the system (description of behavior algorithms)
	Interactions (interaction)	(sequence)	Displays the sequence of message passing between objects and actors
		(communication)	Similar to a sequence diagram, but the main focus is on the structure of interaction between objects
Implementations (implementation)	(component)		Displays system components (programs, libraries, tables, etc.) and links between them	Physical	static	Component
	(deployment)		Displays the placement of components by network nodes, as well as its configuration

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

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

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

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

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

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

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

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

Table 11.6. Linking Models and Diagrams

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

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

4. Define the term "".

10.4. UML DIAGRAM

10.4.1. Types of Visual UML Diagrams

UML allows you to create several types of visual diagrams:

Use Case Diagrams;

Sequence diagrams;

Cooperative charts;

class diagrams;

State diagrams;

Component diagrams;

Placement diagrams.

The diagrams illustrate various aspects of the system. For example, a cooperative diagram shows how objects must interact in order to implement some system functionality. Each chart has its own purpose.

10.4.2. Use Case Diagrams

Use case diagrams depict the interaction between use cases, representing the functions of a system, and actors, representing people or systems that receive or transmit information to that system. An example of a use case diagram for an automated teller machine (ATM) is shown in Figure 1. 10.1.

Rice. 10.1. Use case diagram

The diagram represents the interaction between use cases and actors. It reflects the system requirements from the user's point of view. Thus, use cases are the functions performed by the system, and actors are the stakeholders in relation to the system being created. Diagrams show which actors initiate use cases. They also show when the actor receives information from the use case. In essence, a use case diagram can illustrate the requirements for a system. In our example, the bank customer initiates different use cases: "Withdraw money from the account", "Transfer money", "Deposit money into the account", "Show balance", "Change identification number", "Make payment". The bank teller can initiate the use case "Change Identification Number". From the use case "Make a payment" there is an arrow to the Credit system. Actors can also be external systems, in this case the Credit System is shown exactly as an actor - it is external to the ATM system. An arrow pointing from the use case to the actor indicates that the use case provides some information to the actor. In this case, the Make a Payment use case provides the Credit System with credit card payment information.

You can get quite a lot of information about a system from use case diagrams. This type of diagram describes the overall functionality of the system. Users, project managers, analysts, developers, quality assurance specialists, and anyone interested in the system as a whole can understand what the system should do by examining use case diagrams.

10.4.3. Sequence diagrams

Sequence diagrams represent the flow of events that occur within a use case. For example, the use case "Withdraw money" provides for several possible sequences: withdrawing money, trying to withdraw money when there is not enough money in the account, trying to withdraw money using an incorrect identification number, and some others. A normal scenario for withdrawing $20 from an account (in the absence of problems such as an incorrect identification number or insufficient money in the account) is shown in fig. 10.2.

Figure 10.2. Client Joe's $20 Withdrawal Sequence Diagram

The top of the diagram shows all the actors and objects required by the system to execute the Withdraw Money use case. Arrows correspond to messages passed between the actor and the object or between objects to perform the required functions. It should also be noted that the sequence diagram shows objects, not classes. Classes are types of objects. Objects are concrete; instead of a class Customer the sequence diagram represents a particular customer, Joe.

The use case begins when the customer inserts their card into the reader - this object is shown in the box at the top of the diagram. It reads the card number, opens the Joe account object, and initializes the ATM screen. The screen asks Joe for his registration number. The client enters the number 1234. The screen checks the number on the Joe account object and finds that it is correct. The screen then presents Joe with a menu to choose from, and he selects "Withdraw". The screen asks how much he wants to withdraw, and Joe enters $20. The screen withdraws money from the account. In doing so, it initiates a series of processes performed by the Joe Account object. At the same time, a check is made that the account contains at least $20 and the required amount is deducted from the account. The cash register is then instructed to "dispense check and $20 in cash." Finally, the same "Joe's account" object instructs the card reader to return the card.

So, this sequence diagram illustrates the sequence of actions that implement the "Withdraw money" use case using the specific example of customer Joe withdrawing $20. Looking at this diagram, users get acquainted with the specifics of their work. Analysts see the sequence (flow) of actions, developers see the objects to be created and their operations. Quality control professionals will understand the details of the process and be able to develop tests to verify them. Thus, sequence diagrams are useful to all project participants.

10.4.4. co-op charts

Cooperative diagrams display the same information as sequence diagrams. However, they do it differently and for other purposes. Shown in fig. 10.2 the sequence diagram is shown in fig. 10.3 in the form of a cooperative diagram.

As before, the objects are shown as rectangles, and the actors as figures. If the sequence diagram shows the interaction between actors and objects over time, then there is no connection over time in the cooperative diagram. Thus, it can be seen that the card reader instructs "Joe's account" to open, and "Joe's account" causes the card reader to return the card to the owner. Directly interacting objects are connected by lines. If, for example, the card reader communicates directly with the ATM screen, a line should be drawn between them. The absence of a line means that there is no direct communication between objects.

Rice. 10.3. Cooperative diagram describing the process of withdrawing money from an account

So, the cooperative diagram displays the same information as the sequence diagram, but it is needed for other purposes. Quality control specialists and system architects will be able to understand the distribution of processes between objects. Let's say that some kind of cooperative diagram resembles a star, where several objects are associated with one central object. The system architect may conclude that the system is too dependent on a central facility and needs to be redesigned to distribute processes more evenly. In a sequence diagram, this type of interaction would be hard to see.

10.4.5. class diagrams

Class diagrams reflect the interaction between the classes of a system. For example, "joe's account" is an object. The type of such an object can be considered an account in general, i.e. "Account" is a class. Classes contain data and behaviors (actions) that affect that data. Thus, the Account class contains the identification number of the client and the actions that check it. In a class diagram, a class is created for each type of object from Sequence Diagrams or Co-op Diagrams. The class diagram for the "Withdraw money" use case is shown in Figure 1. 10.4.

The diagram shows the relationships between classes that implement the "Withdraw money" use case. Four classes are involved in this process: Card Reader (card reader), Account (account), ATM (ATM screen) and Cash Dispenser (cash register). Each class on the class diagram is depicted as a rectangle divided into three parts. The first part is the name of the class, the second part is the name of the class. attributes. An attribute is some information that characterizes a class. For example, the class Account (account) has three attributes: Account Number (account number), PIN (identification number) and Balance (balance). The last part contains the operations of the class that reflect it. behavior(actions performed by the class). Lines connecting classes show the interaction between classes.

Rice. 10.4. class diagram

Developers use class diagrams to actually create classes. Tools like Rose generate a class code base that programmers fill in with details in their language of choice. With these diagrams, analysts can show the details of a system and architects can understand its design. If, for example, any class carries too much functional load, this will be visible on the class diagram, and the architect can redistribute it among other classes. The diagram can also be used to identify cases where no relationship has been defined between the communicating classes. Class diagrams should be created to show interacting classes in each use case. You can also build more general diagrams covering all systems or subsystems.

10.4.6. State diagrams

State diagrams are designed to model the various states that an object can be in. While a class diagram shows a static picture of classes and their relationships, state diagrams are used to describe the dynamics of a system's behavior.

State diagrams represent the behavior of an object. So, a bank account can have several different states. It may be open, closed, or the credit on it may be exceeded. The behavior of the account changes depending on the state it is in. The state diagram shows exactly this information. On fig. 10.5 is an example of a state diagram for a bank account.

Rice. 10.5. State diagram for the Account class

This diagram shows the possible states of the account, as well as the process of transition of the account from one state to another. For example, if the client requests to close an open account, the latter goes into the "Closed" state. The customer's requirement is called event, it is the events that cause the transition from one state to another.

When a customer withdraws money from an open account, the account may go into an "overcredit" state. This only happens if the account balance is less than zero, which is represented by the [negative balance] condition in our diagram. Bracketed condition determines when a transition from one state to another may or may not occur.

There are two special states in the diagram - initial and final. The initial state is highlighted with a black dot: it corresponds to the state of the object at the time of its creation. The final state is indicated by a black dot in a white circle: it corresponds to the state of the object immediately before its destruction. A state diagram can have one and only one initial state. At the same time, there may be as many final states as you need, or there may be none at all.

When an object is in a particular state, certain processes can be executed. In our example, when the credit is exceeded, a corresponding message is sent to the client. The processes that occur when an object is in a particular state are called actions.

Statecharts do not need to be created for every class, they are used only in very complex cases. If a class object can exist in multiple states and behave differently in each of them, it would probably need such a diagram. However, in many projects they are not used at all. If statecharts have been built, developers can use them when creating classes.

Statecharts are needed mainly for documentation purposes.

10.4.7. Component diagrams

Component diagrams show what the model looks like at the physical level. It depicts the software components of your system and the relationships between them. There are two types of components: executable components and code libraries.

On fig. 10.6 shows one of the component diagrams for the ATM system. This diagram shows the components of an ATM system client. In this case, the development team decided to build the system using the C++ language. Each class has its own header file and extension file. CPP so that each class is converted to its own components in the diagram. The selected dark component is called package specification and corresponds to the C++ ATM class body file (.cpp file). An unselected component is also called a package specification, but corresponds to a C++ language class header file (.h file extension). ATM component. exe is a task specification and represents the information processing flow. In this case, the processing thread is the executable program.

Components are connected by a dashed line showing the dependencies between them. A system can have multiple component diagrams depending on the number of subsystems or executables. Each subsystem is a package of components.

Component diagrams are used by those project participants who are responsible for compiling the system. The component diagram gives an idea of the order in which the components should be compiled, as well as which executable components will be created by the system. The diagram shows the correspondence of classes to implemented components. So, it is needed where code generation begins.

Rice. 10.6. Component Diagram

10.4.8. Placement diagrams

Location diagrams show the physical location of the various components of a system on a network. In our example, the ATM system consists of a large number of subsystems running on separate physical devices or nodes. The placement diagram for the ATM system is shown in fig. 10.7.

From this diagram, you can learn about the physical layout of the system. ATM client programs will run in multiple locations at different sites. Through closed networks, clients will communicate with the regional ATM server. It will run the ATM server software. In turn, through the local network, the regional server will interact with the banking database server running Oracle. Finally, a printer is connected to the regional ATM server.

So, this diagram shows the physical layout of the system. For example, our ATM system follows a three-tier architecture where the first tier hosts the database, the second tier hosts the regional server, and the third tier hosts the client.

10.7. Placement diagram

The layout diagram is used by the project manager, users, system architect, and operations personnel to determine the physical layout of the system and the location of its individual subsystems. The project manager will explain to the users what the finished product will look like. Operational personnel will be able to plan the work of installing the system.

From the Microsoft Office book author Leontiev Vitaly Petrovich

Diagrams Far from always the numbers in the table allow you to make a complete impression, even if they are sorted in the most convenient way for you. Using the chart templates available in Microsoft Excel, you can get a visual picture of your table data without

From the book Computer 100. Starting with Windows Vista the author Zozulya Yuri

Diagrams Diagrams are used to present tabular data in a graphical form, which can significantly improve the visibility of information, show the ratio of various parameters or the dynamics of their change. Tools are used to insert charts in Word

From the book Effective Office Work author Ptashinsky Vladimir Sergeevich

Charts The most visual feature of Excel is the presentation of the results of calculations or accumulated data in the form of graphs (charts): sometimes the most impressive numbers are not able to convince in the way that even simple graphics can do. Excel has

From an Excel workbook. multimedia course the author Medinov Oleg

Chapter 8 Charts Excel is often used to create documents that represent various statistical and analytical reports. These can be sales reports, tables of air temperature measurements, sociological survey data, etc. Figures are not always

From the book Word 2007. Popular tutorial the author Krainsky I

Building a chart For the first example, you will need to create the table shown in fig. 8.1. Rice. 8.1. Temperature Measurement Table We will build a simple temperature chart based on the data in this table.1. Highlight the filled range in the table.2. Go to

From the book Computer Tutorial author Kolisnichenko Denis Nikolaevich

6.6. Charts In addition to graphic files, you can insert charts into Word documents. Using charts, you can visualize numerical data, for example, track how data changes, see the development of a project in dynamics. Charts turn similar

From the book Object-Oriented Analysis and Design with Example C++ Applications by Butch Gradi

14.9. Diagrams Perhaps it's time to turn dry numbers into graphics, making our table more beautiful and informative? Charts are used for this. Say what you like, but the diagram is perceived better than the table. To build a diagram, you need to select the values by which

From the book Programming Technologies the author Kamaev V A

5.2. Class Diagrams The Essential: Classes and Their Relationships A class diagram shows classes and their relationships, thus representing the logical aspect of a project. A single class diagram represents a particular view of the class structure. At the analysis stage, we

From the book Business Process Modeling with BPwin 4.0 author Maklakov Sergey Vladimirovich

5.4. Object Diagrams Essential: Objects and Their Relationships An object diagram shows the existing objects and their relationships in the logical design of the system. In other words, an object diagram is a snapshot of the flow of events in some configuration.

From the book OrCAD PSpice. Electrical circuit analysis by Keown J.

5.7. Process diagrams. Essential: Processors, Devices, and Connections Process diagrams are used to show the distribution of processes across processors in the physical design of a system. A separate process diagram shows one view of the process structure

From the VBA Book for Dummies author Cummings Steve

10.4. UML DIAGRAM 10.4.1. Types of visual diagrams UMLUML allows you to create several types of visual diagrams: use case diagrams; sequence diagrams; cooperative diagrams; class diagrams; state diagrams; diagrams

From the book Macintosh Tutorial author Skrylina Sofya

1.2.6. Diagram frame Figure 1.2.26 shows a typical example of a decomposition diagram with bounding boxes, called the diagram's frame. Rice. 1.2.26. An example of a decomposition diagram with a wireframe The wireframe contains a title (top of the box) and a footer (bottom).

From the author's book

Timing Charts To get the timing charts for the input and output voltages, you need to slightly modify the input file. As in the previous example, a sinusoidal input voltage will be used: Vi 1 0 sin (0 0.5V 5kHz) Along with transient analysis

From the author's book

Charts and Graphs Only a specialist can see the meaning behind the endless rows of numbers, but anyone can understand (or at least claim to understand) a bar chart or a pie chart. VBA does not have built-in diagramming tools, but such

From the author's book

5.1.14. Charts Charts are a graphical representation of the numerical data of a table. Pages offers several types of charts: Column (Columnar), Stacked Column (Multi-tiered columns), Vag (Histogram), Stacked Vag (Multi-tiered histogram), Line (Linear), Area (Area), Stacked Area (Multi-tiered

From the author's book

5.2.8. Charts A chart is a graphical representation of data from a selected range. To build a chart, follow the following algorithm1. Create a table of calculated values.2. Select the desired range (it may consist of non-adjacent rectangular

The UML is a general-purpose graphical modeling language for the specification, visualization, design, and documentation of all artifacts created in the development of software systems.

There are many good books that describe in detail about UML (sometimes even very detailed), I would like to collect in one place the basic concepts about diagrams, entities and relationships between them for quick recall, something like a cheat sheet.

The note uses materials from books: Ivanov D. Yu., Novikov F. A. Unified modeling language UML and Leonenkov. UML Tutorial.

Let's start with the editor. Under Linux, I tried different UML editors, most of all I liked UMLet, although it is written in Java, it moves very quickly and most of the entity blanks are in it. There is also ArgoUML, a cross-platform UML editor, also written in Java, functionally rich, but slowing down more.

I stopped at UMLet, install it under Arch Linux and ubuntu:

# under Arch Linux yaourt -S umlet # under Ubuntu sudo apt-get install umlet

In UML, all entities can be broken down into the following types:

structural;
behavioral;
grouping;
annotational;

The UML uses four main types of relationships:

Dependency- indicates that changing the independent entity affects the dependent entity in some way. Graphically, a dependency relationship is depicted as a dotted line with an arrow pointing from the dependent entity to the independent entity.

Association- takes place if one entity is directly related to another (or to others - the association can be not only binary). Graphically, an association is depicted as a solid line with various additions connecting related entities.

Generalization is a relationship between two entities, one of which is a particular (specialized) case of the other. Graphically, generalization is depicted as a line with a triangular unfilled arrow at the end, directed from the particular (subclass) to the general (superclass).

Implementations- the implementation relation indicates that one entity is an implementation of another. Graphically, the implementation is depicted as a dotted line with a triangular unfilled arrow at the end, directed from the implementing entity to the implemented one.

AT UML 2 defined 13 chart types. By standards, each chart should have a frame with a rectangle (lower right corner beveled) in the upper left corner, which indicates the chart ID (tag) and title.

Diagrams to depict the structure of the system:

Component diagram (component diagram, tag component);
Deployment diagram (deployment diagram, tag deployment);
Class diagram (class diagram, tag class);
Object diagram (object diagram, tag object);
Internal structure diagram (composite structure diagram, tag class);

Diagrams to depict system behavior:

Synchronization diagram (interaction diagram, tag timing);
Activity diagram (activity diagram, tag activity);
sequence diagram (sequence diagram, tag sd);
Communication diagram (communication diagram, tag comm);
Automaton diagram (state machine diagram, tag state machine);
Interaction overview diagram, tag interaction);

The charts stand out:

Use case diagram (use case diagram, use case tag);
Package diagram (package diagram, tag package);

Usage diagram

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

Considering a use case diagram as a model of a system, one can associate it with a black box model. Each use case defines a sequence of actions that must be performed by the designed system when it interacts with the corresponding actor.

The use diagram uses two types of basic entities: use cases and actors, between which the following basic types of relationships are established.

association relation- This relationship establishes what specific role an actor plays when interacting with an instance of a use case. An association relationship is indicated by a solid line between the actor and the use case. This line may have additional symbols, such as, for example, a name and a multiplicity.

Extension relation- defines the relationship of instances of a single use case with a more general use case, the properties of which are determined based on the way these instances are combined together. Thus, if there is an extension relationship from use case A to use case B, then this means that the properties of an instance of use case B can be supplemented due to the presence of properties in extended use case A.

An extension relationship between use cases is indicated by a dashed line with an arrow (dependency relationship case) pointing away from the use case that is an extension of the original use case.

Generalization relation serves to indicate the fact that some use case A can be generalized to use case B. In this case, use case A will be a specialization of use case B. In this case, B is called an ancestor or parent of A, and use A is a descendant of use case use of V.

Graphically, this relationship is represented by a solid line with an open triangle arrow that points to the parent use case.

A generalization relationship between use cases is used when it is necessary to note that child use cases have all the attributes and behaviors of parent use cases.

Inclusion relation between two use cases indicates that some specified behavior for one use case is included as a component in the behavior sequence of another use case.

An inclusion relationship, from use case A to use case B, indicates that each instance of use case A includes the functional properties specified for use case B.

Graphically, this relationship is represented by a dotted line with an arrow (dependency relationship variant) pointing from the base use case to the included use case.

class diagram

class diagram(class diagram) - the main way to describe the static structure of the system.

The class diagram uses one main type of entities: classes (including numerous special cases of classes: interfaces, primitive types, association classes, etc.), between which the following main types of relationships are established: dependencies, associations, generalizations, implementations.

Dependency relation generally indicates some semantic relationship between two model elements or two sets of such elements that is not an association, generalization, or implementation relationship. A dependency relationship is used in a situation where some change in one model element may require a change in another dependent model element.

A dependency relationship is graphically represented by a dashed line between corresponding elements with an arrow at one end, with the arrow pointing from the dependency's client class to the independent or source class.

Special keywords (stereotypes) can be placed above the arrow:

"access" - serves to indicate the availability of public attributes and operations of the source class for client classes;
"bind" - the client class can use some template for its subsequent parameterization;
"derive" - attributes of the client class can be calculated from the attributes of the source class;
"import" - public attributes and operations of the source class become part of the client class, as if they were declared directly in it;
"refine" - indicates that the client class serves as a refinement of the source class for historical reasons, when additional information becomes available in the course of work on the project.

association relation corresponds to the presence of some relationship between classes. This relationship is indicated by a solid line with additional special symbols that characterize individual properties of a particular association. As additional special characters, the name of the association, as well as the names and multiplicity of the role classes of the association, can be used. The name of an association is an optional element of its designation.

Aggregation relation occurs between several classes if one of the classes is an entity that includes other entities as components. It is used to represent system relationships of the "part-whole" type.

Composition relation is a special case of an aggregation relation. This relationship serves to highlight a special form of the part-whole relationship in which the constituent parts are in some sense within the whole. The specificity of the relationship between them lies in the fact that the parts cannot act in isolation from the whole, i.e., with the destruction of the whole, all its constituent parts are also destroyed.

Generalization relation is a relationship between a more general element (parent or ancestor) and a more specific or special element (child or descendant). As applied to a class diagram, this relationship describes the hierarchical structure of classes and the inheritance of their properties and behavior. This assumes that the descendant class has all the properties and behavior of the ancestor class, and also has its own properties and behavior that are not present in the ancestor class.

automaton diagram

automaton diagram(state machine diagram) or state diagram in UML 1 (state chart diagram) is one way to describe behavior in detail in UML. In essence, automaton diagrams, as the name implies, are a graph of states and transitions of a finite automaton loaded with many additional details and details.

The state diagram describes the process of changing the states of only one class, or rather, one instance of a certain class, that is, it models all possible changes in the state of a particular object. In this case, a change in the state of an object can be caused by external influences from other objects or from the outside. It is to describe the reaction of an object to such external influences that state diagrams are used.

In the automaton diagram, one main type of entity is used - states, and one type of relationship - transitions, but for both of them many varieties, special cases and additional designations are defined. The automaton represents the dynamic aspects of the simulated system in the form of a directed graph, the vertices of which correspond to states, and the arcs correspond to transitions.

Initial state is a special case of a state that does not contain any internal actions (pseudo-states). The object is in this state by default at the initial moment of time. It serves to indicate on the state diagram of the graphical area from which the process of changing states begins.

Final (final) a state is a special case of a state that also does not contain any internal actions (pseudo-states). The object will be in this state by default after the completion of the automaton at the end time.

activity diagram

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

activity diagram(activity diagram) is another way of describing behavior that visually resembles a good old flowchart of an algorithm. Used to simulate the process of performing operations.

The main direction of using activity diagrams is to visualize the features of the implementation of class operations, when it is necessary to present algorithms for their execution.

In the activity diagram, one main type of entities is used - action, and one type of relationship - transitions (transfers of control). Also used are such constructions as forks, mergers, connections, branchings. It is recommended to use a verb with explanatory words as the name of a simple action.

sequence diagram

sequence diagram(sequence diagram) is a way of describing the behavior of the system "by examples".

In the sequence diagram, one main type of entities is used - instances of interacting classifiers (mainly classes, components and actors), and one type of relationship - links through which messages are exchanged.

Possible types of messages (image taken from larin.in):

Communication Diagram

Communication Diagram(communication diagram) - a way of describing behavior, semantically equivalent to a sequence diagram. In fact, this is the same description of the message exchange sequence of interacting instances of classifiers, only expressed by other graphic means.

Thus, in the communication diagram, as well as in the sequence diagram, one main type of entities is used - instances of interacting classifiers and one type of relationship - connections. However, here the emphasis is not on time, but on the structure of relationships between specific instances.

Component Diagram

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

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

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

Placement diagram

Placement diagram(deployment diagram), along with displaying the composition and relationships of system elements, shows how they are physically located on computing resources during execution.

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

Object Diagram

Object Diagram(object diagram) - is an instance of a class diagram.

The object diagram uses one main type of entities: objects (class instances), between which specific relationships are indicated (most often association instances). Object diagrams are of an auxiliary nature - in fact, these are examples (one might say, memory dumps) showing what objects exist and the relationships between them at some particular moment in the system's operation.

Diagram of internal structure(composite structure diagram) is used for a more detailed presentation of structural classifiers, primarily classes and components.

A structural classifier is shown as a rectangle with the name of the classifier at the top. Inside are parts. There may be several parts. Parts can interact with each other. This is indicated by connectors of various kinds. The place on the outer edge of the part to which the connector is attached is called the port. Ports are also located on the outer boundary of the structural classifier.

Interaction Overview Diagram(interaction overview diagram) is a kind of activity diagram with an extended syntax: links to interactions (interaction use) defined by sequence diagrams can act as elements of an overview interaction diagram.

Timing chart

Timing chart(timing diagram) is a special form of a sequence diagram, in which special attention is paid to the change in the states of various instances of classifiers and their time synchronization.

Package diagram

Package diagram(package diagram) is the only tool that allows you to manage the complexity of the model itself.

The main elements of the notation are packages and dependencies with various stereotypes.

Entity-relationship model (ER-model)

analogue class diagrams(UML) can be ER model, which is used in the design of databases (relational model).

Entity-relationship model (ER-model) is a data model that allows you to describe the conceptual schemas of the subject area. The ER model is used in high-level (conceptual) database design. With its help, you can highlight the key entities and designate the relationships that can be established between these entities. wikipedia

Any fragment of the subject area can be represented as a set of entities, between which there is a certain set of relationships.

Basic concepts:

Essence(entity) is an entity that can be identified in some way that distinguishes it from other entities, for example, CLIENT 777. An entity is actually a set of attributes.

Entity set(entity set) - a set of entities of the same type (having the same properties).

Connection(relationship) is an association established between multiple entities.

Domain(domain) - set of values (domain) of the attribute.

There are three types of binary links:

one to one- a single instance of an entity of one class is associated with a single instance of an entity of another class, for example, HEAD - DEPARTMENT;
1 to N or one to many- a single instance of an entity of one class is associated with many instances of an entity of another class, for example, DEPARTMENT - EMPLOYEE;
N to M or many to many- many instances of an entity of one class are associated with many instances of an entity of another class, for example, EMPLOYEE - PROJECT;

Glossary of basic concepts in UML

object- an entity that has a uniqueness and encapsulates the state and behavior.

class- a description of a set of objects with common attributes defining state and operations defining behavior.

interface- a named set of operations that defines a set of services that can be requested by the consumer and provided by the service provider.

Cooperation- a set of objects that interact to achieve some goal.

Actor- an entity that is outside the modeled system and directly interacts with it.

component- a modular part of the system with a well-defined set of required and provided interfaces.

Artifact- an element of information that is used or generated in the software development process. In other words, an artifact is a physical unit of implementation derived from a model element (such as a class or component).

Node- a computing resource on which artifacts are placed and, if necessary, executed.

Behavioral entities are intended to describe behavior. There are only two basic behavioral entities: state and action.

state- a period in the life cycle of an object, being in which the object satisfies a certain condition and performs its own activity or waits for the occurrence of some event.

action- primitive atomic calculation.

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

classifier is a descriptor for a set of objects of the same type.

Extra reading

Fowler M. UML. Fundamentals, 3rd edition
Butch G., Rambo D., Jacobson I. UML language. User guide