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

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

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

1.2.6. Diagram frame In Fig. Figure 1.2.26 shows a typical example of a decomposition diagram with bounding boxes called the diagram frame. Rice. 1.2.26. Example of a decomposition diagram with a wireframe. The wireframe contains a title ( top part frames) and basement (lower part).

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

Charts and Graphs Only an expert can discern the meaning behind endless rows of numbers, but anyone can understand (or at least claim to understand) a histogram or pie chart. VBA does not have built-in tools for creating diagrams, but such

5.1.14. Charts Charts are graphical representations of numerical data in a table. Pages offers several types of charts: Column, Stacked Column, Bar Chart, Stacked Bar Chart, Line, Area, Stacked Area

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

What is UML?

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

As Wikipedia says

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

Application

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

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

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

Automation

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

Conclusion

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

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

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

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

Why you need several types of diagrams

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Types of charts

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

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

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

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

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

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

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

Use case diagram

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

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

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

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

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

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

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

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

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

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

UML 1.4.2 – "ISO/IEC 19501:2005. Information Technology. Open distribution processing. Unified Modeling Language (UML). Version 1.4.2" (English "Information technology. Open distributed processing. Unified modeling language (UML). Version 1.4.2");

UML 2.4.1 - "ISO/IEC 19505-1:2012. Information technology. Object Management Group Unified 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. Object Management Group Unified Modeling Language (OMG UML). Part 2. Superstructure" (eng. "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 UML is shown in the following figure.

Rice. 11.1. UML structure

11.2. UML semantics and syntax

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

Syntax – ways of combining words and their forms into phrases and sentences, combining sentences into complex sentences, ways of creating statements as part of a text.

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

11.3. UML notation

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

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 combination of diagram elements;

Explanatory (annotative) – a comment on a diagram element.

The following table shows short description the main entities used in graphical notation, and the main ways of displaying them.

Table 11.1. Entities

Type	Name	Designation	Definition (semantics)
Structural	(class)		Many objects that have general structure and behavior
	(object)		An abstraction of a real or imagined entity with clearly defined conceptual boundaries, personality, state, and behavior. From a UML point of view, objects are instances of a class (instances of an entity)
	(actor)	Engineer path services	An entity external to the system that interacts with and uses the system functionality to achieve certain goals or solve particular problems. So an actor is external source or information receiver
	(use case)		Description of the actions performed by the system, which leads to a significant result for the actor
	(state)		A description of a 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 to solve 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)		The area of ​​specific interaction between actor instances and objects
	(activity partition)		A group of operations (area of ​​responsibility) performed by one 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 the occurrence of an unusual situation
Explanatory	Note (comment)		Comment for the element. Attaches to the commented element with a dashed line

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

Some of the above entities according to imply them detailed description on decomposition diagrams. On the top-level diagram they are marked with a special icon or label.

The following table provides a description of all types relations UML used in diagrams to indicate relationships between entities.

Table 11.3. Relationship

Name	Designation	Definition (semantics)
Association		Relation describing meaningful connection between two or more entities. Most general form relationship
Aggregation		A subtype of association that describes the “part”–“whole” relationship, in which the “part” can exist separately from the “whole.” The rhombus is indicated from the “whole” side. The relationship is specified only between entities of the same type
Composition		A subtype of aggregation in which the “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). The arrow side indicates an independent entity
Generalization		The relationship between a generalized entity (ancestor, parent) and a specialized entity (descendant, daughter). The triangle is indicated from the parent's side. The 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 arrow side indicates the entity that defines the action (interface or use case)

For association, aggregation and composition can be specified multiplicity (eng. multiplicity), characterizing the total number of instances of entities participating in the relationship. It is usually indicated on each side of the relationship near the corresponding entity. The multiplicity can be indicated in the following ways:

- * – any number of copies, including none;

Non-negative integer number – 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..*);

Listing 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 participating in dependency, generalization, and implementation is always assumed to be 1.

The following table provides a description expansion mechanisms , used to clarify 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. Expansion Mechanisms

In addition to stereotypes indicated as a string of text in quotation marks, graphic stereotypes can be used in diagrams. The following figure shows examples of standard and stereotypical display.

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

Rice. 11.2. Examples of standard and stereotypical class display

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

Table 11.5. Diagrams

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

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

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

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

Profile diagram - similar with a description of the classes included in them;

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

For the purpose of an enlarged conceptual representation of the internal architecture of the system, the majority of the construction allows the use of 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 model of a system, 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 constructed. At the same time, you don't have to create separate types of charts if it's not necessary. 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 (clarify) diagrams for system models.

Table 11.6. Relationship between models and diagrams

The table below does not show a testing model, since as part of its construction, diagrams are not developed, but checked (tested) for completeness and consistency.

Some of the diagrams after their construction require development and clarification as part of the development of the next model ( technological process). So, for example, they should be clarified during development. In models.

4. Define the concept " ".