Creating diagrams in uml language. Unified Modeling Language UML

It was enough to add a new component, which is somewhat simpler.

When using the second option, in two different scenarios, in addition to adding a new component, we needed to change the component that processes letters.

Table 6. Results of evaluation of two indexer architecture options.

+ denotes the ability not to change the component,- - need to change a component,

* - the need to add one component

6. In general, the first architecture looks better than the second in the proposed scenarios. Its only drawback is the inability to incrementally supply input data to components. If this is eliminated by making components capable of consuming data incrementally, this architecture becomes almost ideal because it is easily extensible - to solve many additional tasks you only need to add components to the overall pipeline.

The second architecture, despite the gain in incrementality, loses overall. Its main problem is that the letter handler component is too specifically constructed. The need to change it in several scenarios shows that it is necessary to combine the letter handler and the end-of-word handler into a single component that produces entire words, after which the resulting architecture will be in no way inferior to the corrected first one.

UML. Kinds UML diagrams

To represent architecture, or rather, the various structures included in it, it is convenient to use graphical languages. On currently The most developed and most widely used of them is unified modeling language(Unified Modeling Language, UML), although quite often the architecture of a system is described simply by a set of named rectangles connected by lines and arrows that represent possible connections.

UML suggests using 8 types of diagrams to describe architecture. The 9th type of UML diagrams, use case diagrams (see Lecture 4), is not related to architectural representations. In addition, other types of diagrams can be used to describe the internal structure of components or scenarios of user actions and other elements that are often not related to the architecture. In this course we will not analyze UML diagrams in detail, but will limit ourselves to an overview of their main elements necessary for common understanding the meaning of what is depicted in such diagrams.

UML diagrams are divided into two groups - static and dynamic charts.

Static charts

Static diagrams represent either entities and relationships between them that are constantly present in the system, or summary information about entities and relationships, or entities and relationships that exist in some certain moment time. They do not show the ways in which these entities behave. This type includes class diagrams,objects, components and deployment diagrams.

Class Diagrams(class diagrams) show classes or types of system entities, characteristics of classes (fields and operations) and possible relationships between them. An example of a class diagram is shown in Fig. 31.

Classes are represented by rectangles divided into three parts. In the upper part they show the name of the class, in the middle - a set of its fields, with names, types, access modifiers (public '+', protected '#', private '-') and initial values, in the lower part - a set of class operations. For each operation, its access modifier is shown and

signature.

In Fig. 31 classes depicted Account, Person, Organization, Address, CreditAccount and

abstract class Client.

The CreditAccount class has a private field maximumCredit of type double, as well as a public method getCredit() and a protected method setCredit().

Interfaces, i.e. types that have only a set of operations and do not define how they are implemented are often shown as small circles, although they can also be shown as regular classes. In Fig. 31 presents the AccountInterface interface.

Figure 31. Class diagram.

Three types of connections between classes are most often used - compositional connections, links, inheritance and implementation connections.

Composition describes a situation in which objects of class A include objects of class B, and the latter cannot be separated (an object of class B, which is part of an object of class A, cannot be part of another object of class A) and exists only within the framework of the enclosing objects (they are destroyed when the enclosing object is destroyed) .

The composition in Fig. 31 is the relationship between the Organization and Address classes.

Reference link (or weak aggregation) means that an object of some classA has as a field a reference to an object of another (or the same) classB, and references to the same object of classB can be present in several objects of classA.

Both the composition and the reference relationship are represented by arrows leading from class A to class B. The composition additionally has a filled diamond at the beginning of this arrow. Two-way reference relationships, indicating that objects can have references to each other, are shown as lines without arrows. This connection is shown in Fig. 31 between classes

Account and Client.

These connections can be described plurality, indicating how many objects of class B can be associated with one object of class A . It is depicted as a text label near the end of the arrow containing the exact number or lower and upper bounds, with infinity represented by an asterisk or the letter n. For double-sided

Multiple connections can be shown on both sides. In Fig. The 31 multiplicities depicted for the relationship between the Account and Client classes indicate that one client may or may not have many accounts, and an account is always associated with exactly one client.

Class inheritance depicted by an arrow with an empty tip leading from the heir to the ancestor. In Fig. 31 the CreditAccount class inherits from the Account class, and the classes

Person and Organization - to the Client class.

Implementing Interfaces is shown as a dotted arrow with an empty tip leading from the class to the interface it implements, if it is shown as a rectangle. If the interface is depicted as a circle, then the implementation connection is shown as a regular solid line (in this case, there is no ambiguity in its interpretation). Such a connection is shown in Fig. 31 between the Account class and the interface

AccountInterface.

One class uses another if that other class is the type of the first class's parameter or operation result. Sometimes usage relationships are shown as dotted arrows. An example of such a relationship between the Person class and the AddressKind enumeration type can be seen in Fig. 31.

Reference links implemented in the form associative arrays or maps

Such a connection, depending on a certain set of keys, determines a set of value links - they are shown using arrows that have a rectangle listing the types and names of the keys adjacent to the image of the class from which the arrow goes. The multiplicity at the end of the arrow denotes the number of links corresponding to one set of key values.

In Fig. 31 such a relationship leads from the Person class to the Address class, showing that a Person class object can have one address for each value of the key key, i.e. one home and one work address.

Class diagrams are used more often than other types of diagrams.

Object Diagrams(object diagrams) show part of the system objects and connections between them in a specific state or in total, over a certain time interval. Objects are represented by rectangles with object role identifiers (in the context of the states shown in the diagram) and types. Homogeneous collections of objects can be represented by overlapping rectangles.

Such diagrams are used quite rarely.

Figure 32. Object diagram.

Component Diagrams(component diagrams) represent components in several senses - the atomic components of a system in terms of its assembly, configuration management and deployment. Build and configuration management components are typically source code files, dynamically loaded libraries, HTML pages etc., deployment components are JavaBeans, CORBA, COM, etc. components. For more information on such components, see Lecture 12.

The component is depicted as a rectangle with several rectangular or other shaped “teeth” on the left side.

Links showing dependencies between components are represented by dotted arrows. One component depends on another if it cannot be used in the absence of that other component in the system configuration. Components can also implement interfaces.

Diagrams of this type are rarely used.

Figure 33. Component diagram.

In the component diagram shown in Fig. 33, you can also see packages depicted as “folders”, more precisely - rectangles with rectangular “growths” above the upper left corner. Packages are namespaces and a means of grouping diagrams and other UML model elements - classes, components, etc. They can appear on class and component diagrams to indicate dependencies between them and individual classes and components. Sometimes such a diagram may only contain packages with dependencies between them.

Deployment diagrams(deployment diagrams) show the decomposition of the system into physical devices various types- servers, workstations, terminals, printers, routers, etc. - and connections between them, represented by various kinds of network and individual connections.

Physical devices, called system nodes (nodes), are depicted as cubes or parallelepipeds, and the physical connections between them are represented as lines.

Deployment diagrams can show how system deployment components are tied (either momentarily or permanently) to physical devices

For example, to indicate that the AccountEJB EJB component runs on the application server and the AccountInfoEditor applet runs on workstation bank operator.

Figure 34. Deployment diagram.

Creating additional visual and documentary support for a program is a labor-intensive and tedious process: it takes a lot of time and seems completely unnecessary if the architecture software simple or standard. However, in practice, programmers are not always faced with such tasks.

Why UML didn't take off

“Today programming is not an engineering science, but applied mathematics. At the same time, programmers immediately learn to write code,” explains Anatoly Shalyto, head of the Department of Programming Technologies at ITMO University.

People tried to work with UML, hoping that it would become a kind of “silver bullet”, but it did not gain widespread popularity. Researchers identify three main obstacles that have prevented the widespread adoption of state diagrams as a common means of describing algorithms and complex program behaviors.

Firstly, to describe behavior, in addition to state diagrams, it was proposed to use other types of diagrams, but the rules defining their interaction were not regulated.

“Many people think the language is too long,” says researcher and entrepreneur Jordi Cabot. “This is due to the large number of diagrams available in UML.”

A similar fate awaited many other solutions, which, however, are not full-fledged alternatives to UML. We are talking about business process modeling notation (BPMN), entity-relationship models (ERM), data flow diagrams (DFD), state diagrams, etc. As Cris Fuhrman notes, all this is nothing more than communication tools.

Transition to slot machines

Automatic programming is an approach that can facilitate the specification generation process. During operation, graphs are created in which, under the influence of external or any other input influences transitions between states are carried out and output “pulses” are formed. To do this, a text version is first generated terms of reference, in which the customer specifies detailed work desired solution.

After this they announce symbols input and output influences, sources and receivers of information, and then a diagram is drawn. Transition graphs allow the customer to better understand what the programmer will do.

Having a connection diagram and a transition diagram, using a formal transformation, you can build a code that implements an automaton in a programming language. The specifications then become part of the system design documentation. Project documentation is compiled in natural language and usually contains a statement of the problem, a description of the structure and behavior of the system, and examples of its use.

Automatic description in OOP

Mapping a separate class to each control object ensures that the efforts of developers to identify these objects at the modeling stage do not disappear at the implementation stage. Moreover, each request or command has access only to a strictly defined part of the computational state.

In general, the process of designing a system with complex behavior can be described as follows:

1. Carrying out object decomposition, when the system is divided into many independent interacting entities.
2. Mapping entities to classes, defining class interfaces and relationships.
3. Isolating those entities that have complex behavior - it is for their description that the automatic approach will be used.
4. Setting a set of control states for each entity. Requests and commands are mapped to the input and output variables of the control machine, and interface components are mapped to its events. The control machine itself is built on their basis.
5. Implementation of manual classes in the selected object-oriented language. Code generation can be done either automatically or manually.

UML also allows software developers to reach agreement on graphic symbols for presentation general concepts(such as class, component, generalization, aggregation and behavior) and focus more on design and architecture.

Story

Prerequisites for the emergence of a modeling language UML emerged in connection with the rapid development in the second half of the 20th century of object-oriented programming languages ​​(Simula 67, Smalltalk, Objective C, C++, etc.). Due to the ongoing complication of created software products there was a need to take into account more and more new capabilities of languages ​​and development tools when analyzing, formulating requirements and in the design process software applications. For example, in the short period of time from 1989 to 1994, the number of object-oriented tools grew from a dozen to more than fifty. However, many developers have found it difficult to choose a modeling language that would fully meet all their needs. As a result, a new generation of development methods emerged, among which the Booch method, created by Jacobson, became especially popular Object-Oriented Software Engineering (OOSE) and designed by Rambo (Object Modeling Technique (OMT). In addition to them, there were other completed technologies, for example Fusion, Shlaer-Mellor And Coad-Yourdon, however, all of them had not only advantages, but also significant disadvantages.

Before UML 1.x

UML 1.x

In the wake of growing interest in UML, companies such as Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software joined the development of new versions of the language within the UML Partners consortium , Texas Instruments and Unisys . The result collaboration became the UML 1.0 specification, released in January 1997. It was followed in November of the same year by version 1.1, which contained improvements to the notation as well as some semantic extensions.

Subsequent releases of UML included versions 1.3, 1.4, and 1.5, published in June, September, and March 2003, respectively.

UML 1.4.2 has been adopted as an international standard by ISO/IEC 19501:2005.

UML 2.x

The formal specification for UML 2.0 was published in August 2005. The semantics of the language have been significantly refined and expanded to support the Model Driven Development - MDD methodology. Latest version UML 2.5 was published in June 2015.

UML 2.4.1 has been adopted as an international standard by ISO/IEC 19505-1, 19505-2.

Diagrams

The following types of diagrams are used in UML (to avoid ambiguity, notations in English are also given):

UML is a unified graphical modeling language for describing, visualizing, designing and documenting OO systems. UML is designed to support the process of modeling software based on the OO approach, organize the relationship of conceptual and program concepts, and reflect the problems of scaling complex systems. UML models are used at all stages life cycle PS, starting with business analysis and ending with system maintenance. Different organizations may use UML as they see fit, depending on their problem areas and the technologies they use.

A Brief History of UML

By the mid-90s, various authors had proposed several dozen OO modeling methods, each of which used its own graphical notation. Moreover, each of these methods had its own strengths, but did not allow us to build a sufficiently complete model of the PS, to show it “from all sides,” that is, all the necessary projections (See article 1). In addition, the lack of an OO modeling standard made it difficult for developers to choose the most suitable method, which prevented the widespread adoption of the OO approach to software development.

At the request of the Object Management Group (OMG), the organization responsible for the adoption of standards in the field of object technologies and databases, the urgent problem of unification and standardization was solved by the authors of the three most popular OO methods - G. Butch, D. Rambo and A. Jacobson, who combined efforts created version UML 1.1, approved by OMG in 1997 as a standard.

UML is a language

Any language consists of a vocabulary and rules for combining words to create meaningful constructions. This is, in particular, how programming languages ​​are structured, such as UML. Its distinctive feature is that the language dictionary is formed by graphic elements. Each graphic symbol has a specific semantics associated with it, so a model created by one developer can be clearly understood by another, as well as by a software tool that interprets UML. From here, in particular, it follows that a software model presented in UML can be automatically translated into an OO programming language (such as Java, C++, VisualBasic), that is, if there is a good visual modeling tool that supports UML, having built the model , we will also receive a sample program code corresponding to this model.

It should be emphasized that UML is a language, not a method. It explains what elements to create models from and how to read them, but says nothing about which models should be developed and in what cases. To create a method based on UML, it is necessary to supplement it with a description of the software development process. An example of such a process is the Rational Unified Process, which will be discussed in subsequent articles.

UML Dictionary

The model is represented in the form of entities and relationships between them, which are shown in diagrams.

Entities are abstractions that are the main elements of models. There are four types of entities - structural (class, interface, component, use case, collaboration, node), behavioral (interaction, state), grouping (packages) and annotation (comments). Each type of entity has its own graphical representation. Entities will be discussed in detail when studying the diagrams.

Relationship show various connections between entities. UML defines the following relationship types:

• Addiction shows such a connection between two entities when a change in one of them - independent - can affect the semantics of the other - dependent. Dependency is represented by a dotted arrow directed from the dependent entity to the independent entity.
• Association is a structural relationship showing that the objects of one entity are related to the objects of another. Graphically, an association is shown as a line connecting the associated entities. Associations serve to navigate between objects. For example, the association between the classes “Order” and “Product” can be used to find all products specified in a specific order, on the one hand, or to find all orders that contain this product, on the other. It is clear that the corresponding programs must implement a mechanism that provides such navigation. If navigation in only one direction is required, it is indicated by an arrow at the end of the association. A special case of association is aggregation - a relationship of the form “whole” - “part”. Graphically, it is highlighted with a diamond at the end near the essence-whole.
• Generalization is the relationship between a parent entity and a child entity. Essentially, this relationship reflects the property of inheritance for classes and objects. The generalization is shown as a line ending with a triangle directed towards the parent entity. The child inherits the structure (attributes) and behavior (methods) of the parent, but at the same time it can have new structure elements and new methods. UML allows multiple inheritance, where an entity is related to more than one parent entity.
• Implementation– the relationship between an entity that defines a specification of behavior (interface) with an entity that defines the implementation of this behavior (class, component). This relationship is commonly used when modeling components and will be described in more detail in subsequent articles.

Diagrams. UML provides the following diagrams:

• Diagrams describing the behavior of the system:
• State diagrams
• Activity diagrams,
• Object diagrams,
• Sequence diagrams,
• Collaboration diagrams;
• Diagrams describing the physical implementation of the system:
• Component diagrams;
• Deployment diagrams.

Model Control View. Packages.

We have already said that in order for a model to be well understood by humans, it is necessary to organize it hierarchically, leaving a small number of entities at each level of the hierarchy. UML includes a means of organizing a hierarchical representation of a model - packages. Any model consists of a set of packages that may contain classes, use cases, and other entities and diagrams. A package can contain other packages, allowing hierarchies to be created. UML does not provide separate package diagrams, but they may appear in other diagrams. The package is depicted as a rectangle with a bookmark.

What UML provides.

• hierarchical description of a complex system by identifying packages;
• formalization of functional requirements for the system using the apparatus of use cases;
• detailing system requirements by constructing activity diagrams and scenarios;
• identifying data classes and constructing a conceptual data model in the form of class diagrams;
• identifying classes that describe the user interface and creating a screen navigation scheme;
• description of the processes of interaction between objects when performing system functions;
• description of object behavior in the form of activity and state diagrams;
• description of software components and their interaction through interfaces;
• description of the physical architecture of the system.

And the last thing...

Despite all the attractiveness of UML, it would be difficult to use in real software modeling without visual modeling tools. Such tools allow you to quickly present diagrams on the display screen, document them, generate program code templates in various OO programming languages, and create database schemas. Most of them include the possibility of reengineering program codes - restoring certain projections of the software model by automatically analyzing source codes of programs, which is very important to ensure compliance between the model and codes and when designing systems that inherit the functionality of predecessor systems.

Unified language modeling (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. Unified Modeling Language for Object Management Group (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 (building models), which combines natural and formal languages ​​for representation basic concepts(elements of the model) and mechanisms for their expansion.

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 interaction 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		A relationship that describes a 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 describes 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 the 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 " ".