Uml component diagram description. Modeling in UML. Implementation diagrams. Interaction overview charts

15.2. Purpose and composition of the component diagram

The component diagram allows you to determine the composition of software components, which can be source, binary and executable code, as well as to establish dependencies between them.

When developing component diagrams, the following goals are pursued:

Specification of the general structure of the source code of the system;

Specification of the executable version of the system.

This diagram provides a consistent transition from logical to physical representation of the system in the form of software components. Some components can only exist at compile time program code, others - at the stage of its execution. The main elements of a diagram are components, interfaces and dependencies between them. In addition, it can display the key classes included in the components.

Component (English component) is the physical part of the system. Components, which are files with source code of classes, libraries, executable modules, etc., which must have a consistent set of interfaces. The following graphic symbols are used to represent them graphically.

Rice. 15.2. Component examples

Inside the rectangle is written the name of the component and possibly some additional information in the form of a tagged value.

Components can have the following standard stereotypes:

- "file" - any file, except for the table:

o "executable" - program (executable file);

o "library" - static or dynamic library;

o "source" - a file with the source code of the program;

o "document" - other files (for example, help file);

- "table" - database table.

Inside a component, just like a class, additional sections can be allocated, in which the provided or required interfaces and classes, methods (operations), the name of the component file (artifacts), etc. are specified.

Rice. 15.3. Component with sections

Interface (English interface) is an externally visible, named set of operations that a class, component or subsystem can provide to another class, component or subsystem to perform its functions. In some programming languages, in particular in Java, an interface is a separate class that is included and implemented (instantiated) as part of the program code of operations as part of other classes. On the component diagram, the interface is displayed in the same way as on (to the left of the component, the interfaces required for operation, to the right - provided).

Rice. 15.4. Interface display methods

Association relation displayed between components and their interfaces. Addiction relationship means the dependence of the implementation of some components on the implementation of others. This is possible in the following cases:

In the methods of the classes of one component (dependent), methods are called or the attributes of the classes of another component (independent) are called;

A component consists of other components (for example, when building an executable file from files with source codes);

A component reads or writes data to another component;

Relationship between database tables;

Due to the multipurpose purpose of a component diagram, the following rules and guidelines should be followed during its development.

1. Before developing component diagrams, it is necessary to decide what physical parts (files) the software system will consist of. In this case, two tasks must be solved - the distribution of classes in source code files and in subsystems. In the latter case, the distribution of classes into specialized (functionally oriented to the subject area) packages can help. At this stage, attention should be paid to such an implementation of the system that would provide the possibility of reusing the code due to rational decomposition of the system, i.e., minimize the number of connections between components.

2. When specifying the general structure of the source code of the system, it is necessary to take into account the specifics of the programming language with which the components are implemented. In particular, in Java, it is recommended to describe a separate class in a separate file, despite the fact that the language allows you to describe several classes in one file and use the mechanism of internal classes. The component diagram used for this purpose is shown in the following figure.

Rice. 15.5. Fragment of a component diagram specifying the structure of the source code

The diagram in Fig. 15.5 shows the composition of the classes (files) that make up the executable component iskraPUT.jar, as well as the dependencies between the classes.

3. For the specification of an executable version of the system, it is necessary to have a preliminary topology of the system, that is, a sketch. For each node in the network, a component diagram can be built, defining the set of files required for the operation of the subsystem (s) at a separate workstation.

Rice. 15.6. Example of a component diagram specifying the composition of components at a user's workplace

4. A diagram can represent the dependency relationships between components and the classes they contain. This information is essential to ensure consistency between the logical and physical representations of the system. In this case, dependence can be shown in two ways:

Show classes separately from the component and associate the component with each class in a dependency relationship. For example, in Fig. 15.5 instead of components with the "java" extension, show the corresponding classes;

Display the classes inside the component symbol.

6. To visually display the specifics of components, you can use graphic stereotypes instead of a standard component symbol with a string stereotype.

The 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 is supported by many object-oriented CASE products.

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

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

· Class diagram (class diagram) - for modeling the static structure of the classes of the system and the connections between them;

Behavior diagrams

· Interaction diagrams;

· Sequence diagrams - to simulate the process of exchanging messages between objects within a single use case;

· Collaboration diagram - for modeling the process of messaging between objects within one use case;

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

· Activity diagram - for modeling the behavior of the system in the framework of various use cases, or modeling activities;

Implementation diagrams:

Component diagrams - to model the hierarchy of components (subsystems) of an information system;

· Deployment diagram - to model the physical architecture of the designed information system.

In fig. 1.1 presents an integrated model of the information system, including the basic diagrams that should 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 by discussing with the user the functions that he would like to implement in a given information system. In the UML, a use case is depicted as follows:

Fig. 2. Use case

Actor is the role that the 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, the actor can also be an external information system that needs some information from the system. Show actors in your diagram only when they really need some use cases. In the UML, actors are represented as shapes:

Fig. 3. Actor (actor)

There are three main types of actors:

· Users;

· Systems;

· Other systems interacting with this;

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

4.2.1. Relationships Between Use Cases and Actors

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

Communication,

Inclusion (include),

Extension (extend),

Generalization.

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

Fig. 4. Communication link example

Inclusion link applies in situations where there is a piece of system behavior that is repeated in more than one use case. These links are usually used to model a reusable function.

Extension link is used to describe changes in the normal behavior of a system. It allows one use case to use functionality another use case.

Fig. 5. Example of connection of inclusion and extension

Generalization link indicates that multiple actors or classes have general properties.

Fig. 6. Generalization link example

4.3.

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

Message Is the means by which the sender object requests the recipient object to perform one of its operations.

Informative message Is a message that supplies the recipient object with some information to update its state.

Request message (interrogative) Is a message requesting the issuance of some information about the recipient object.

Imperative message Is a message that asks the recipient to take 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 that occur within a single use case.

All of the 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 required functions.

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

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

Rice. 7. Example of a sequence diagram

4.3.2. Collaboration diagram

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

In a collaboration diagram, as in a sequence diagram, arrows indicate messages exchanged for a given use case. Their temporal sequence is indicated by the numbering of messages.

Rice. 8. Example of a cooperation diagram

4.4. Class diagram

4.4.1. General information

Class diagram defines the types of classes of the system and various kinds of static links that exist between them. Class diagrams also depict class attributes, class operations, and constraints that apply to relationships between classes.

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

The class diagram depicts the following elements:

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

· Class - a description of the general properties of a group of similar objects;

· Interface is an abstract class that defines a set of operations that an object of an arbitrary class associated with this interface provides to other objects.

4.4.2. Class

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

The behavior of an object in UML is understood as any rules for the interaction of an object with the outside world and with the data of the object itself.

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

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

The middle section contains a list of attributes

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

Any of the sections of attributes and operations may not be displayed (as well as both at once). No need to draw for missing section 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. Example class diagram

4.4.2.1.Class stereotypes

Class stereotypes are a mechanism for categorizing classes.

There are three main class stereotypes defined in the UML:

Boundary

Entity

Control.

4.4.2.2.Boundary Classes

Boundary classes are classes that are located at the border 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 the boundary classes, you need to examine the use case diagrams. For every interaction between an actor and a use case, there must be 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 greatest value for the user, and therefore they often use terms from the subject area in their names. Typically, 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 controlling class is responsible for coordination, but it does not carry any functionality itself, since the other classes do not send it a lot of messages. Instead, he sends many messages himself. The manager class simply delegates responsibility to other classes, for this reason it is often referred to as the manager class.

There may be other control classes in the system that are common to multiple use cases. For example, there might be a SecurityManager class that is responsible for monitoring security events. The TransactionManager class is responsible for coordinating 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.

Since the attributes are contained within the class, they are hidden from other classes. Therefore, you may need to specify which classes are allowed to read and modify attributes. This property is called attribute visibility.

An 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 the attribute. In UML notation, the 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 with a "-" according to UML notation.

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 Assumes that this attribute is generic, 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 a situation when the value of an attribute is changed by all classes of the system. Instead, the logic for modifying an attribute will be wrapped in the same class as the attribute itself. The visibility parameters you set will affect the generated code.

4.4.2.6.Operations

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

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

In a class diagram, you can display both the names of the operations and the names of the operations along with their parameters and return type. To reduce the workload of the diagram, it is useful to show only the names of operations on some of them, and on others their full signature.

In the UML, operations have the following notation:

Operation Name (Argument: Data Type of Argument, Argument2: Data Type of Argument2, ...): Return Type

There are four different types operations:

Implementation operations;

Control 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 step must be easily traceable to the corresponding requirement. This is achieved at various stages of the simulation. An activity is derived from a message in an interaction diagram, messages are derived from a detailed description of an event flow that is generated based on a use case, and the latter is derived from requirements. The ability to trace this entire chain ensures that every requirement is implemented in code, and every piece of code implements a requirement.

Control operations

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

Access operations

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

Auxiliary operations

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

To identify transactions, follow these steps:

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

2. Consider control operations. You might 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 enables a class to learn about the attributes, operations, and relationships of another class. In other words, for one class to be able to send a message to another in a sequence diagram or a cooperative diagram, there must be a relationship between the two.

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

Communication association

Association is the semantic link 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, bi-directional associations are drawn as a simple line without arrows or with arrows on either side. On a unidirectional association, only one arrow is depicted showing its direction.

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

Associations can be reflective. Reflexive association assumes 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 the definitions made in the other. For example, class A uses methods of class B. Then when class B changes, you need to make the corresponding changes in class A.

Dependency is depicted by a dashed line drawn between two chart elements, and the element anchored to the end of an arrow is considered to be dependent on the element anchored to 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 statements required to support the communication will be generated.

Link aggregation

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

Rice. 11. Communication aggregation

In addition to simple aggregation, the UML introduces a stronger form of aggregation called composition. According to the composition, an object-part can only belong to a single whole, and, in addition, 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 seen as part of the definition of aggregation, but it is always implied when the multiplicity of roles is 1..1; for example, if it is necessary to delete a Customer, then this deletion must apply to Orders (and, in turn, to Order Lines).

Component Diagram - A physical layer diagram that serves to
views of software components and dependencies
between them.
Component diagram is designed for the following
goals:
Visualization of the general structure of the source code
software system.
Specification of the executable version of the software
systems.
Ensuring reusability of individual
fragments of program code.
Representation of conceptual and physical base layouts
data.

Component

- a model element representing some modular
part of a system with encapsulated content,
whose specification is interchangeable in its
surroundings.
The name of the component instance is written in the same way as the name
life lines on interaction diagrams as follows
format (BNF):
<имя-экземпляра-компонента>::=[<собственное-имякомпонента>] [‘:’<имя-типа>],
in this case, the proper name of the component is written with
a lowercase letter, and as the name of the component instance
at least one term must be present.

Examples of images of a simple component and a component with interfaces

IDialog
"Component"
Order
ISe ns or
IApplication
"Component"
Control p

Examples of component images in black and white box notation

"Component"
Order
"Provided interf aces"
The location of your macaw
Escort
"Required interf aces"
Ordered
Customer
"Component"
Order
"Provided interf aces"
The location of your macaw
Escort
"Required interf aces"
Ordered
Customer
"Realizations"
Title okOrder
St rokaTov macaw
"Artifacts"
Order.jar

Interfaces

Provided interface -
the interface that the component offers for its
surroundings.
Required interface - the interface
which the component needs from its environment for
performance of the declared functionality, contract or
behavior.
Ordering
Product
"Component"
Product
Ordering
Product
Escort
Invoice
"Component"
Order
Customer
Order Title
order
element
1
*
Item String
Location
Goods

Representation of interfaces in the form of a classifier symbol with dependency and implementation relationships

"Interface"
Ordering
Product
"Use"
find iPoI mei ()
set number ()
will receive Det ali ()
"Component"
Order
"Interface"
Location of the Goods
assign ()
change()
will receive Det ali ()

Ports

A port defines a distinguishable point of interaction between
component and its environment or between
component and its internals
Port name is optional
If there is no port name, its type is associated with the type
the interface to which the port is associated.
Ordering
Product
"Component"
Order
Customer
Order Title
order
Accompaniment
element
1
*
Item String
Location
Goods

Assembly connector

- a connector that connects two components in
the context of the provided and required services.
Accompaniment
Accompaniment
"Component"
Order
Order my product
"Component"
:Order
Order my product
Order my product
Order my product
"Component"
Product
"Component"
:Product

10. Example of a diagram of components with collecting connectors for the same interfaces

: Canceled Order
Location
Location
Goods
:Warehouse
Customer
Customer
Person
:Order
: Physical
Face
Location
Organization
Accompanying
:The supplier
:Company
Product
Ordering
Accompaniment
Product
:Service
:Product

11. Delegation connector

- a connector that binds the external contract of a component to
implementation of this behavior by the internals of this
component.
A delegate connector performs one of the following tasks:
Transmitting messages or signals to the port
component from the outside, for processing in some internal
part of a component or other port.
Transmission of messages or signals from some
inside the component, for processing into an external port
component.
Location
Goods
"Component"
Order
: Order Title
: Item String
Customer

12. An example of the internal structure of a component instance

Location
Goods
"Component"
:Score
"Delegate"
Location
Goods
"Component"
:Order
Customer
Customer
"Component"
: Physical
Face
Check
Ordering
Product
Ordering
Product
"Component"
:Product
"Delegate"
Check

13. Example of a dependency relationship between a component

Canceled Order
Physical
Face
Warehouse
Order
The supplier
Company
Service
Product

14. Dependency Relationships in Component Diagram with Interfaces

Location
Goods
Person
Customer
Physical
Face
Order
Location Tracking
Ordering
Product
The supplier
Accompaniment
Service
Ordering
Product
Product
Organization
Company

15. Realization

- specialization of dependency relationship for communication
components with classifiers that implement
functionality of this component
Component implementation can be further labeled
with the "implement" stereotype
"Component"
Order
<>
Heading
Order
<>
Line
Goods

16. Image of graphic stereotypes of G. Buch's components

Dialog.dll
Inde x.htm l
Conte xt .hlp
M ain.cpp

17. Graphic stereotypes of J. Conallen's components

The server page represents a web page
containing scripts to be executed by the server.
These scripts can interact with server side
resources such as databases, business logic and external
systems.
The operations of the implemented class components are
script functions, and their attributes are variables,
visible within this page.
<>

18. Client page

<>
Represents a Web page in HTML format, and
data, interface elements, and even business logic.
Client pages are rendered by client browsers
and may contain scripts that are interpreted
browser.
Client page operations can match
functions contained in script descriptors
pages.
The attributes of the client page correspond to the declared
in script descriptors the variables that are available
any function within this page.

19. Form

>
It is a set of input fields and is a part
client page.
Form is converted directly to HTML descriptor
.
Form attributes can represent input fields, text
fields, switches, checkboxes, hidden fields HTML forms.
There are no operations associated with the form, since they cannot be
encapsulate in it.
Any operations of interaction with the form are
properties of the containing page.

20. Frameset

<>
It is a container consisting of several
Web pages.
The rectangular viewing area is divided into several
frames.
Each frame can be associated with one object with
stereotype "target", however this is optional.
The frame content can be a Web page or other
frame. The frameset is converted directly to
web page frameset and HTML descriptor .

21. Purpose

<>
Represents a named area of the browser window, in
which web pages can be displayed.
The target name matches the target name.
Usually the target is one of the dialing frames.
However, the target could also be a new browser window. For the purpose
a destination can be set where it will be displayed
new web page.
Target name must be unique for each customer
systems.

22. Web page

<>
The browser can request a Web page by its name.
This component can optionally contain
client or server scripts.
Typically web pages are text files, access
which can be accessed through the web server.
However, they can also be compiled modules,
downloadable and run by a web server.
In any case, when accessing such a page stored in
file or executable by the web server, it generates
HTML document that is sent in response to
browser request.

23. JSP and Servlet

This component represents
Web pages that implement
the JSP code of the back-end of the application. This stereotype
only applicable to applications
which uses
Java Server Pages technology.
This component represents
Java servlet. Stereotype
only applicable to applications
supporting servlets
Sun.
<page >>
<>
24. Independent task number 8
Perform current testing: questions 34-36
Design a Component Diagram for ATM
Show the following components: Home
program, ATM service program,
Transaction, ATM devices.
IATMBank interface
Place on the diagram all classes represented by
on class diagram
Depict the relationship between them
UML language

Unified Modeling Language ( UML ) is the standard tool for creating "blueprints" software... Using the UML, you can visualize, specify, design, and document artifacts of software systems.

UML is suitable for modeling any system: from information systems enterprise-wide to distributed Web -applications and even embedded real-time systems. UML Is a language for visualizing, specifying, constructing and documenting software system artifacts. A modeling language like UML is standard means for drawing up software “blueprints”.

To understand any non-trivial system, you have to develop a large number of interrelated models. As applied to software systems, this means that a language is needed with which it is possible to describe from various points of view the representations of the architecture of the system throughout its development cycle.

UML is a graphical specification language, which means the construction of accurate and complete graphical models regarding analysis, design and implementation, which must be adopted during the development and deployment of a software system.

UML is a language design, and the models created with its help can be directly translated into various programming languages. In other words, the UML model can be mapped to languages such as Java, C ++, Visual Basic , and even relational database tables.

This mapping of a model to a programming language allows direct design: the generation of code from a UML model into a specific language. You can also solve the inverse problem: to reconstruct the model according to the existing implementation.

The UML solves the problem of documenting the system architecture and all its details, provides a language for formulating system requirements and defining tests, and finally provides a means for modeling work during project planning and versioning.

Using the UML is effective in:

· enterprise-wide information systems;

· banking and financial services;

· telecommunications;

· On transport;

· defense industry, aviation and astronautics;

· retail trade;

· medical electronics;

· Science;

· Distributed Web-systems.

The UML is not limited to software modeling. It allows you to simulate, say, the workflow in legal systems, the structure and operation of patient care systems in hospitals, and hardware design.

1 Structure and components of the language UML

1.1 General principles

The constructive use of the UML is based on an understanding of the general principles of modeling complex systems and process features object-oriented analysis and design (OOAP). The choice of expressive means for building models of complex systems is based on several principles.

The first is the principle of abstraction, which prescribes to include in the model only those aspects of the system being designed that are directly related to the performance of the system's functions or its intended purpose. In this case, all the minor details are omitted so as not to overly complicate the process of analyzing and researching the resulting model.

The second principle of constructing models of complex systems is the principle of multi-model. This means that no single representation of a complex system is sufficient to adequately express all of its features.

Another principle of applied systems analysis is the principle of hierarchical construction of models of complex systems. This principle prescribes to consider the process of building a model at different levels of abstraction or detail in the framework of fixed representations.

Thus, the OOAP process can be represented as a step-by-step descent from the most general models and representations of the conceptual layer to more specific and detailed representations of the logical and physical layer. At the same time, at each stage of OOAP, these models are sequentially supplemented with more and more details, which allows them to more adequately reflect various aspects of a specific implementation of a complex system.

Object-oriented analysis and system design involves the use of a language vocabulary UML , which includes three types of building blocks: entities, relationships, diagrams.

1.2 Entities

The main object-oriented blocks are entities. In language UML there are four types of entities: structural, behavioral, grouping, annotation.

Structural entities Are nouns in UML models. They are static parts of the model that correspond to the conceptual or physical elements of the system. There are five types of conceptual and logical entities.

Class(Class ) Is a description of a collection of objects with common attributes, operations, relations and semantics (Fig. 3). A class implements one or more interfaces.

Rice. 3 Classes

Interface(Interface ) Is a collection of operations that define a set of services provided by a class or component. The interface describes the externally visible behavior of an element (Figure 4). An interface rarely exists on its own — it is usually attached to an implementing class or component.

Rice. 4 Interface

Cooperation(Collaboration ) defines interaction, and represents a set of roles that work together to produce some cooperative effect. Cooperation has both a structural and a behavioral aspect - one and the same class can take part in several cooperatives (Fig. 5).

Rice. 5 Cooperation

Precedent(Use case ) Is a description of the sequence of actions performed by the system that produces an observable result that is significant for a certain actor( Actor ). The use case is used to structure the behavioral entities of the model, and are implemented through cooperation (Figure 6).

Rice. 6 Precedent

Active class (Active class ) is a class whose objects are involved in one or more processes ( Threads ), and can initiate a control action. An active class differs from an ordinary class in that the activity of its objects is carried out simultaneously with the activity of other elements. A graphically active class is drawn in the same way as a simple class, but the bounding box is drawn with a bold line and usually includes the name, attributes, and operations (Figure 7)

Rice. 7 Active class

Components and nodes correspond to the physical entities of the system.

Component(Component ) Is a physical replaceable part of the system that corresponds to a certain set of interfaces and provides its implementation (Fig. 8). A component is a physical packaging of logical elements (classes, interfaces and cooperation), for example, COM + or Java Beans as well as source files.

Rice. 8 Component

Knot(Node ) Is an element representing a computational resource that has memory and processing capability. A set of components can be located in a node, and also migrate from one node to another (Fig. 9).

Rice. 9 Node

There are also varieties of these seven entities: actors, signals, utilities (class types), processes and threads (active class types), applications, documents, files, libraries, pages, and tables (component views).

Behavioral entities (Behavioral things ) are dynamic components of the UML model. These are verbs of the language: they describe the behavior of the model. There are only two types of behavioral entities.

Interaction(Interaction ) Is a behavior, the essence of which is the exchange of messages between objects to achieve a specific goal. Interaction describes both a single operation and the behavior of a collection of objects. Interaction involves a number of other elements, such as a message (Figure 10), a sequence of actions (behavior triggered by a message), and communication (between objects).

Rice. 10 Message

Machine(State machine ) Is a behavior algorithm that determines the sequence of states through which an object or interaction passes throughout its life cycle in response to various events, as well as reactions to these events (Fig. 11). Using an automaton, you can describe the behavior of an individual class or cooperation of classes. A number of other elements are associated with the automaton: states, transitions (from one state to another), events (entities that initiate transitions), and types of actions (reaction to a transition).

Rice. 11 Status

Interactions and automata are semantically related to various structural elements such as classes, collaborations, and objects.

Grouping entities are the organizing parts of the model, these are the blocks into which the model can be decomposed. The main grouping entity is the package.

Package(Package ) Is a universal mechanism for organizing elements into groups (Fig. 12). Structural, behavioral, and even other grouping entities can be placed in the package. Unlike the components that exist while the program is running, packages are purely conceptual in nature, that is, they exist only during development.

Rice. 12 Packages

There are also package variations, such as wireframes ( Frameworks ), models and subsystems.

Annotation entities - explanatory parts of the UML model. These are comments for additional description, clarification, or comment on any element of the model. There is only one base type of annotation elements- note.

Note(Note ) Is a symbol for displaying comments attached to an element or a group of elements (Fig. 13).

Rice. 13 Note

Notes are used to provide comments or constraints to diagrams that can be expressed in informal or formal text. There are variations on this element, such as requirements, which describe some desired behavior in terms of external to the model.

1.2 Relationships

In the UML four types are defined relationship: dependency, association, generalization, implementation. These relationships are the main connecting building blocks in UML.

Addiction(Dependency ) Is a semantic relationship between two entities, in which a change in one of them, independent, can affect the semantics of the other, dependent (Fig. 14).

Rice . 14 Addiction relationship

Association(Association ) Is a relation that describes a set of connections between objects. A variation of the association is aggregation( Aggregation) - the structural relationship between the whole and its parts (Fig. 15). An association graphic can include cardinality and role names (Figure 16).

Rice . 1 5 Aggregation

Rice . 16 Association names

Generalization(Generalization) - this is a “specialization / generalization” relationship (Fig. 17), in which a specialized element object (child) can be substituted for a generic element object (parent or ancestor). Thus, the descendant ( Child ) inherits the structure and behavior of its parent ( Parent).

Rice. 17 Generalization

Finally, realization( Realization) - this is a relationship between classifiers, in which one classifier defines a "contract", and the other guarantees its implementation (Fig. 18).

Rice. 18 Implementation

Implementation relationships occur in two cases: first, between interfaces and the classes or components that implement them, and second, between use cases and the collaborations that implement them.

1.2 Diagrams

Diagram in UML Is a graphical representation of a set of elements, depicted as a connected graph with vertices (entities) and edges (relations), used to visualize the system from different points of view. V UML there are 8 types of diagrams (Fig. 1 9 ).

Rice. 19 Integrated model of a complex system in UML notation

On the class diagram ( C lass diagram) depicts classes, interfaces, objects, and collaborations, and their relationships. Used in modeling object-oriented systems.

On the use case diagram (Use case diagram) presents the use cases and actors (a special case of classes), as well as the relationship between them. They are used to model the behavior of a system.

Diagrams sequences (Sequence diagram) and cooperation(Collaboration diagram) are special cases of interaction diagrams. On interaction diagrams links between objects (messages that objects can exchange) are represented. Interaction diagrams refer to the dynamic view of the system. Moreover, the sequence diagrams reflect the temporal ordering of messages, and cooperation diagrams - the structural organization of objects exchanging messages. These charts can be converted to each other.

On the state diagrams ( S tatechart diagrams ) an automaton is presented that includes states, transitions, events, and types of actions. State diagrams are used to model the behavior of an interface, class, or cooperation that depends on a sequence of events.

Activity diagram (Activity diagram) represent the transitions of the control flow between objects from one activity to another within the system.

Component diagram (Component diagram) represents dependencies between components. Component diagrams map to one or more classes, interfaces, or collaborations.

On the deployment diagram (Deployment diagram) shows the configuration of the processing nodes of the system and the components placed in them.

UML diagram is a specialized graphical description language designed for object modeling in the development of various software. This language has a wide profile and is an open standard that uses various graphical notations to create an abstract model of the system. The UML was created to provide definition, visualization, documentation, and design of all kinds of software systems. It is worth noting that the UML diagram itself is not a programming language, but it does provide for the possibility of generating a separate code based on it.
Why is it needed?
The UML doesn't end with modeling all kinds of software. Also, this language is actively used today for modeling various business processes, conducting systems engineering, as well as displaying organizational structures.
With the help of the UML, software developers can enforce complete agreement on what they use. graphic symbols to represent general concepts such as component, generalization, class, behavior, and aggregation. This achieves a greater degree of focus on architecture and design.
It is also worth noting that there are several types of such diagrams.
Class diagram
A UML class diagram is a static structure diagram designed to describe the structure of a system, as well as show attributes, methods, and dependencies between several different classes.
It is worth noting the fact that there are several points of view on the construction of such diagrams, depending on how they will be used:
Conceptual. In this case, the UML class diagram describes the model of a specific domain, and only classes of applied objects are provided in it.
Specific. The diagram is used in the design process of various information systems.
Implementation. The class diagram includes all kinds of classes that are directly used in the program code.

Component diagram
A UML Component Diagram is a fully static structural diagram. It is intended to demonstrate the division of a certain software system into various structural components, as well as the connections between them. A UML component diagram as such can use all sorts of models, libraries, files, packages, executable files, and many other elements.
Composite / Composite Structure Diagram
The UML Composite / Composite Structure Diagram is also a static structure diagram, but it is used to show the internal structure of classes. If possible given diagram can also demonstrate the interaction of elements that are in the internal structure of a class.
A subtype of them is the UML-diagram of cooperation, which is used to demonstrate the roles, as well as the interaction of various classes within the boundaries of cooperation. They are quite handy when you need to model design patterns.
It is worth noting that UML class diagram types and composite structure types can be used at the same time.
Deployment diagram
This diagram is used in order to simulate working nodes, as well as all kinds of artifacts that were deployed to them. UML 2 deploys artifacts to various nodes, while the first version deploys exclusively components. Thus, the UML deployment diagram is used primarily by the second version.
A manifest dependency is formed between the artifact and the component that it implements.
Object diagram
This view allows you to see a full or partial snapshot of the system being created at a certain point in time. It completely displays all instances of classes of a particular system, indicating the current values of their parameters, as well as the links between them.
Package diagram
This diagram is structural in nature, and its main content is all kinds of packages, as well as the relationship between them. In this case, there is no strict separation between several structural diagrams, as a result of which their use is most often encountered solely for convenience, and does not carry any semantic meaning. It is worth noting that different elements can provide other UML diagrams (examples: packages and the package diagrams themselves).
Their use is carried out in order to ensure the organization of several elements into groups according to a certain criterion, in order to simplify the structure, and also to organize work with the model of this system.
Activity diagram
A UML activity diagram depicts the decomposition of a specific activity into several component parts. In this case, the concept of "activity" refers to the specification of a certain executable behavior in the form of parallel, as well as coordinated sequential execution of various subordinate elements - nested types of activities and various actions, united by threads coming from the outputs of a certain node to the inputs of another.
UML activity diagrams are often used to model various business processes, parallel and sequential computations. Among other things, they simulate all kinds of technological procedures.
Automaton diagram
This view is also called a UML state diagram. Has a presented state machine with simple and composite states and transitions.
A state machine is a sequence specification different conditions through which a certain object passes, or interaction in response to some events in its life, as well as the object's response to such events. A state machine that uses a UML statechart is attached to the source element and used to define the behavior of its instances.
The so-called dragon-schemes can be used as analogs of such diagrams.
Use case diagrams
The UML use case diagram depicts all the relationships that arise between actors, as well as the various use cases. Its main task is to implement itself as a full-fledged means with which the customer, end user or a developer can collaboratively discuss the behavior and functionality of a particular system.
If a UML use case diagram is used in the process of modeling a system, then the analyst is going to:
Clearly separate the simulated system from its environment.
Identify the actors, ways of their interaction with this system, as well as its expected functionality.
Establish in the glossary as a subject area the various concepts that relate to detailed description the functionality of this system.

If a usage diagram is developed in UML, the procedure begins with a textual description, which is obtained when working with a customer. At the same time, it is worth noting the fact that various non-functional requirements in the process of drawing up a model of use cases are completely omitted, and a separate document will already be formed for them.
Communications
A communication diagram, just like a UML sequence diagram, is transitive, that is, it expresses interaction in itself, but at the same time demonstrates it different ways, and, if necessary, with the desired degree of accuracy, you can convert one to another.
The communication diagram depicts the interactions that occur between the various elements of the composite structure, as well as the roles of the cooperation. The main difference from a sequence diagram is that it clearly indicates the relationship between several elements, and time is not used as a separate dimension.
This type It has a completely free format for ordering several objects and links in the same way as it is done in an object diagram. If there is a need to maintain the order of messages in this free format, they are chronologically numbered. Reading this diagram starts with the original message 1.0, and then continues in the direction that messages are passed from one object to another.
Most of these diagrams show exactly the same information that a sequence diagram provides us, however, because it uses a different way of presenting information, certain things in one diagram become much easier to identify than in another. It is also worth noting that a communication diagram more clearly shows which elements each individual element interacts with, while a sequence diagram more clearly shows in what order the interactions take place.
Sequence diagram
A UML sequence diagram demonstrates the interactions between multiple objects, which are ordered according to their time of occurrence. This diagram displays the time-ordered interactions between multiple objects. In particular, it displays all objects that take part in the interaction, as well as the complete sequence of messages exchanged by them.
The main elements in this case are the designations of various objects, as well as vertical lines showing the passage of time and rectangles that provide the activity of a particular object or the performance of any function by it.
Collaboration diagram
This type of diagrams allows you to demonstrate interactions between several objects, abstracting from the sequence of broadcasting messages. This type of diagrams in a compact form displays absolutely all transmitted and received messages of a certain object, as well as the formats of these messages.
Due to the fact that sequence diagrams and communication diagrams are simply different views of the same procedures, Rational Rose provides the ability to create a communication diagram from a sequence diagram or vice versa, and also performs their fully automatic synchronization.
Interaction overview charts
These are UML diagrams, which are a subset of activity diagrams that include both Sequence elements and control flow constructs.
It is worth noting the fact that this format combines Collaboration and Sequence diagram, which provide an opportunity from different points of view to consider the interaction between several objects in the generated system.
Synchronization diagram
Represents Alternative option a sequence diagram that clearly demonstrates the change in state on the lifeline with a specific timeline. Can be quite useful in various real-time applications.
What are the benefits?
It is worth noting several advantages that distinguish the UML use diagram and others:
The language is object-oriented, as a result of which the technologies for describing the results of the analysis and design carried out are semantically close to programming methods in all kinds of object-oriented languages of the modern type.
Using this language, the system can be described from almost any possible point of view, and in the same way, various aspects of its behavior are described.
All diagrams are relatively easy to read, even after a relatively quick familiarity with its syntax.
UML allows you to expand, as well as introduce your own graphical and textual stereotypes, which contributes to its use not only in software engineering.
The language has become quite widespread, and is also developing quite actively.

Flaws
Despite the fact that building UML diagrams has a lot of its advantages, quite often they are criticized for the following shortcomings:
Redundancy. In the vast majority of cases, critics say that the UML is too large and complex, and often this is unjustified. It includes a lot of redundant or practically useless constructions and diagrams, and most often such criticism goes to the second version, and not the first, because in newer revisions there are more compromises "developed by the committee".
Various semantic inaccuracies. Because the UML is defined by a combination of itself, English, and OCL, it lacks the stiffness that is inherent in languages that are precisely defined by the technique of formal description. In certain situations, the abstract syntax of OCL, UML and English start to contradict each other, while in other cases they are incomplete. The inaccuracy of the description of the language itself affects both users and tool providers alike, which ultimately leads to incompatibility of tools due to unique way interpretation of various specifications.
Problems in the process of implementation and study. All of the above problems create certain difficulties in the process of introducing and learning the UML, and this is especially true when the leadership forces engineers to use it forcibly, while they do not have prior skills.
The code mirrors the code. Another opinion is that it is not beautiful and attractive models that are important, but the working systems themselves, that is, the code is the project. In line with this view, there is a need to develop a more efficient way to write software. The UML is appreciated for approaches that compile models to regenerate executable or source code. But in reality, this may not be enough, because the language lacks Turing completeness properties, and each generated code will ultimately be limited by what a UML interpreter tool can assume or define.
Load mismatch. This term comes from the theory of systems analysis to determine the inability of the input of a certain system to perceive the output of another. As with any standard notation system, the UML can represent some systems in a more efficient and concise way than others. Thus, the developer is more inclined towards those solutions that are more comfortable for weaving all the strengths of the UML, as well as other programming languages. This problem is more obvious in the event that the development language does not comply with the basic principles of the object-oriented orthodox doctrine, that is, it does not try to work in accordance with the principles of OOP.
Tries to be versatile. UML is a modeling language general purpose, which tries to ensure compatibility with any processing language available today. In the context of a specific project, in order for the design team to be able to achieve the ultimate goal, it is necessary to select the applicable capabilities of that language. In addition, possible ways of limiting the scope of the UML in a particular area go through a formalism that is not fully formulated, but which itself is an object of criticism.

Thus, the use of this language is not relevant in all situations.