Simulation diagrams. Basic diagrams of the UML language. Interaction Overview Diagrams

UML Model(UML model) is a set of a finite set of language constructs, the main of which are entities and relationships between them.

The entities and relationships of the model themselves are instances of the metaclasses of the metamodel.

Considering the UML model from the most general positions, we can say that it is a graph (more precisely, a loaded multi-pseudo-hyper-digraph), in which vertices and edges are loaded with additional information and can have a complex internal structure. The vertices of this graph are called entities, and the edges are called relations.. The rest of the section provides a quick (preliminary) but complete overview of available entity types and relationships. Luckily, there aren't too many of them. In subsequent chapters of the book, all entities and relationships are considered again, in more detail and with examples.

1.4.1. Essences

For convenience of overview, entities in the UML can be divided into four groups:

• structural;
• behavioral;
• grouping;
• annotational.

Structural entities, as you might guess, are intended to describe the structure. Typically, structural entities include the following.

An object(object) 1 is an entity that has uniqueness and encapsulates state and behavior.

Class(class) 2 - description of a set of objects with common attributes that define the state and operations that define behavior.

Interface(interface) 3 is 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(collaboration) 4 - a set of objects that interact to achieve some goal.

Actor(actor) 5 is an entity that is outside the modeled system and directly interacts with it.

∇ Such a relationship certainly exists, which is expressed in Fig. Diagram Type Hierarchy for UML 1 as a dependency relationship with the "refine" stereotype.

∇∇ In UML 1, there was an involuntary association between a collaboration diagram and an entity of the same name, which was not entirely true and sometimes misleading.

∇∇∇ In UML 2, the syntactic and semantic load of the state diagram has changed so much that the name no longer reflects the content.

A list of new diagrams and their names adopted in this book is given below.

• Composite Structure diagram
• Package diagram
• State machine diagram
• Communication diagram
• Interaction Overview diagram
• Timing diagram

On fig. Diagram Type Hierarchy for UML 2 (Part 1 and 2) a class diagram showing the relationship of diagrams in UML 2.

Later in this chapter, we will describe all thirteen canonical diagrams very briefly in order to have some context and vocabulary for what follows. Details are set out in the remaining chapters of the book.

But before moving on to the next section, let's make one small digression about how the standard requires charts to be formatted. The general chart presentation template is given below.

There are two main design elements: an outer frame and a label with the name of the chart. If everything is simple with the frame - it is a rectangle that bounds the area in which the elements of the diagram should be located, then the name of the diagram is written in a special format shown in Fig. Chart notation.

This complex tab shape is not supported by all tools. However, this is not necessary, since semantics is primary, and notation is secondary. In what follows, we use a rectangle as the chart label throughout, and this should not cause misunderstanding.

Possible tags (types) for charts are shown in the following table. The tags offered by the standard are written in the second column. However, as practice has shown, the rules proposed by the standard are not always convenient and logically justified, therefore the third column of the table contains a reasonable alternative in our opinion.

Tab. Chart types and tags

Chart Title	Tag (standard)	Tag (suggested)
Usage diagram	use case or uc	use case
class diagram	class	class
automaton diagram	state machine or stm	state machine
activity diagram	activity or act	activity
sequence diagram	interaction or sd	sd
Communication Diagram	interaction or sd	comm
Component Diagram	component or cmp	component
Placement diagram	not determined	deployment
Object Diagram	not determined	object
Diagram of internal structure	class	class or component
Interaction Overview Diagram	interaction or sd	interaction
Timing diagram	interaction or sd	timing
Package diagram	package or pkg	package

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, as a rule, 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 "".

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

Benefits of UML

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

Types of UML Diagrams

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

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

Hierarchy of UML diagram types,
represented by a class diagram

Structural diagrams

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

UML Class Diagram Example

Behavior Diagrams

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

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 in 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 placed 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.

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, as 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 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 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 "#" character.

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, in order 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).