home / Programs/ Basic diagrams of the UML language. UML Modeling

Basic diagrams of the UML. UML Modeling

UML or Unified Modeling Language - a graphical description language for object modeling in development software... But the use of UML is not limited to IT, another large area of practical application of UML is business process modeling, systems engineering and mapping of organizational structures. The UML enables software developers to reach an agreement on graphic symbols to present general concepts and concentrate on design and development.

UML advantages

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

Types of UML Diagrams

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

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

UML diagram type hierarchy,
represented by class diagram

Structural diagrams

Class diagram is a key element in object-oriented modeling. With the help of this diagram (in fact, through classes, their attributes, methods and dependencies between classes) describes the domain model and the structure of the modeled system.
Component diagram displays the split program code into large blocks (structural components) and shows dependencies between them. Components can be packages, modules, libraries, files, etc.
Object diagram shows a complete or partial slice of the modeled system at a given moment in time. It represents class instances (objects), their state (current attribute values) and relationships between them.
Composite structure diagram demonstrates the internal structure of classes and, if possible, the interactions between the elements of this structure.
Package diagram shows packages and relationships between them. This type of diagrams serves to simplify the structure of the model (and, accordingly, to work with it) by combining the elements of the model into groups according to certain criteria.
Deployment diagram simulates deployment software components ov ( artifacts) on computing resources / hardware components ( nodes).
Profile diagram describes an extension mechanism that allows the UML to be tailored to a variety of domains and industries.

Example UML Class Diagram

Behavior diagrams

Activity diagram shows actions ( actions) of which some activity ( activity). Activity diagrams are used to model business processes, workflows, sequential and parallel computing.
Use case diagram(or use case diagram) describes the relationship between the actors (characters) and the use cases of the modeled system (its capabilities). The main purpose of a diagram is to be a one-stop-shop for customers, developers, and end users to collaboratively discuss a system — its capabilities and behavior.
State diagram depicts the dynamic behavior of an entity, showing how this entity, depending on its current state reacts to various events. This is essentially a state diagram from the theory of atoms.
Communication diagram(v early versions cooperation diagram) shows the interactions between the parts of the composite structure and the roles of the collaboration. The diagram clearly indicates the relationship between elements (objects).
Sequence diagram used to visualize a sequence of object interactions. Shows the life cycle of a given object and the interaction of actors (actors) within a use case, the sequence of messages they exchange.
Interaction overview chart includes a portion of the sequence diagram and control flow constructs. Helps to consider the interaction of objects from different points of view.
Synchronization diagram- a separate subtype of interaction diagrams, specializing in timing. Diagrams of this kind are used to study the behavior of objects over a certain period of time.

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.

Using the UML, software developers can enforce a complete convention in the graphical notations used 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 splitting of a certain software system on a variety of structural components, as well as connections between them. UML component diagram as such can use all kinds 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, this diagram can also demonstrate the interaction of elements found in the internal structure of the 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 image. 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 hard division between several structural diagrams, as a result of which their use is most often found 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 specification of a sequence of different states through which a certain object passes, or interaction in response to some events in its life, as well as the object's responses 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 provide itself as a full-fledged means by which a customer, an end user, or some developer can jointly 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.
Set in the glossary as a subject area various concepts that relate to a detailed description of 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 is distinguished by 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 the communication diagram more clearly shows which elements each one interacts with. separate element, while the sequence diagram shows more clearly 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.

disadvantages

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 newer revisions contain large quantity 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 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. Inaccurate description of the language itself affects both users and tool providers alike, which ultimately leads to incompatibility of tools due to the unique way of interpreting different 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. According to this opinion, there is a need to develop more effective method writing 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 in any standard systems notation, 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 general-purpose modeling language that seeks to be compatible 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.

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

The entities and relationships of the model themselves are instances of the meta-classes of the metamodel.

Considering UML model from the most general point of view, we can say that this is a graph (more precisely, a loaded multi-pseudo-hyper-digraph) in which the vertices and edges are loaded with additional information and can have a complex internal structure. The vertices of this graph are called entities, and the edges are relations... The rest of the section contains a cursory (preliminary), but full overview available types of entities and relationships. Fortunately, there are not too many of them. In subsequent chapters of the book, all entities and relationships are considered again, in more detail and with examples.

1.4.1. Entities

For ease of viewing, entities in UML can be subdivided into four groups:

structural;
behavioral;
grouping;
annotational.

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

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

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

Interface(interface) 3 is a named set of operations that defines a set of services that can be requested by a consumer and provided by a service provider.

Cooperation(collaboration) 4 - a collection of objects that interact to achieve a goal.

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

∇ Such a relationship certainly exists, which is expressed in Fig. Diagram type hierarchy for UML 1 as a dependency relationship with a refine stereotype.

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

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

A list of the new charts and their names used in this book is shown below.

Diagram internal structure(Composite Structure diagram)
Package diagram
State machine diagram
Communication diagram
Interaction Overview diagram
Timing diagram

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

Later in this chapter we will very briefly describe all thirteen canonical diagrams in order to have a certain context and vocabulary for later presentation. The details are set out in the remaining chapters of the book.

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

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

The indicated complex shape of the tab is not supported by all tools. However, this is not necessary, since semantics are primary and notation is secondary. From now on, we will use a rectangle as a label for the diagram throughout, and this should not cause any confusion.

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

Tab. Chart types and tags

Chart title	Tag (standard)	Tag (suggested)
Usage diagram	use case or uc	use case
Class diagram	class	class
Automaton diagram	state machine or stm	state machine
Activity diagram	activity or act	activity
Sequence diagram	interaction or sd	sd
Communication diagram	interaction or sd	comm
Component diagram	component or cmp	component
Placement diagram	indefined	deployment
Object diagram	indefined	object
Internal structure diagram	class	class or component
Interaction overview diagram	interaction or sd	interaction
Synchronization diagram	interaction or sd	timing
Package diagram	package or pkg	package

11.1. Structure of the Unified Modeling Language

Unified Modeling Language (UML) in currently is the de facto standard for describing (documenting) the results of the design and development of object-oriented systems. UML development began in 1994 by Grady Booch and James Rambeau of 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 the status of an international standard:

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

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

Rice. 11.1. UML structure

11.2. UML semantics and syntax

Semantics - a section 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 the text.

Thus, when applied to the UML, semantics and syntax define a style of presentation (model building) that combines natural and formal languages to represent basic concepts(model elements) and mechanisms for their expansion.

11.3. UML notation

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

The UML defines three entity type :

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

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

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

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

Table 11.1. Entities

Type of	Name	Designation	Definition (semantics)
Structural	(class)		The set of objects that have general structure and behavior
	(object)		An abstraction of a real or imagined entity with clearly defined conceptual boundaries, individuality (identity), state and behavior. From a UML perspective, objects are class instances (entity instances)
	(actor)	Engineer path services	An entity external to the system that interacts with the system and uses it functionality to achieve certain goals or to solve particular problems. Thus, the actor is external source or information receiver
	(use case)		Description of the actions performed by the system, which leads to a result that is significant for the actor
	(state)		Description of the moment in the life of an entity when it satisfies a certain condition, performs some activity or waits for the occurrence of some event
	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 defining a service (set of services) provided by a class or component
	(node)		The physical part of the system (computer, printer, etc.) that provides resources for solving the problem
Grouping	(package)		General mechanism for grouping elements. Unlike a component, a package is a purely conceptual (abstract) concept. Particular cases of the package are the system and the model
	(fragment)		The area of specific interaction between actor and object instances
	(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 which may be interrupted as a result of a non-standard situation
Explaining	Note (comment)		Item comment. Attaches to the commented item with a dashed line

In some sources, in particular [,], behavioral entities are also distinguished 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 the decomposition diagrams. In the diagram top level they are marked with a special icon or label.

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

Table 11.3. Relationship

Name	Designation	Definition (semantics)
Association		A relationship that describes a meaningful relationship between two or more entities. Most general form relationship
Aggregation		A subtype of association describing the relationship "part" - "whole", in which the "part" can exist separately from the "whole". The rhombus is indicated from the "whole" side. The relationship is indicated only between entities of the same type
Composition		A subtype of aggregation in which "parts" cannot exist separately from the "whole". As a rule, "parts" are created and destroyed at the same time as the "whole"
Dependency		A relationship between two entities in which a change in one entity (independent) can affect the state or behavior of another entity (dependent). An independent entity is indicated on the side of the arrow
Generalization		The relationship between a generic entity (ancestor, parent) and a specialized entity (child, child). The triangle is specified from the parent's side. The relationship is indicated only between entities of the same type
Realization		A relationship between entities, where one entity defines an action that the other 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 (English multiplicity), which characterizes 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 specified in the following ways:

- * - any number of copies, including none;

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

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

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

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

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

The following table describes mechanisms to expand used to clarify the semantics of entities and relationships. In general, the extension mechanism is a string of text enclosed in brackets or quotation marks.

Table 11.4. Extension mechanisms

Name	Designation	Definition (semantics)
Stereotype (stereotype)	« »	A designation that specifies the semantics of a notation element (for example: a dependency with the "include" stereotype is considered an inclusion relation, and a class with a "boundary" stereotype is a boundary class)
Guard condition (guard condition)		Boolean condition (for example: or [identification completed])
Limitation (constraint)	{ }	Rule limiting the semantics of the model element (for example, (execution time less than 10ms))
Tagged value (tagged value)	{ }	New or qualifying property of a notation element (for example: (version = 3.2))

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


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

Rice. 11.2. Examples of standard and stereotyped class display

Diagram is a grouping of notation elements to represent some aspect of the 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

Diagram			Appointment
				by the degree of physical realization	by displaying dynamics	by displayed aspect
(use case)			Displays system functions, interaction between actors and functions	Logical	Static	Functional
(class)			Displays a set of classes, interfaces and relationships between them	Logical or physical	Static	Functional and informational
(package)			Displays a set of packages and the relationship between them	Logical or physical	Static	Component
Behaviors (behavior)	(state machine)		Displays the states of an entity and transitions between them during its life cycle	Logical	Dynamic	Behavioral
	(activity)		Displays business processes in the system (description of behavior algorithms)
	Interactions (interaction)	(sequence)	Displays the sequence of passing messages between objects and actors
		(communication)	Similar to a sequence diagram, but the emphasis is on the structure of interactions between objects
Implementation (implementation)	(component)		Displays system components (programs, libraries, tables, etc.) and links between them	Physical	Static	Component
	(deployment)		Displays the placement of components by hosts, as well as its configuration

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

An object diagram is 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 interacting with other classes;

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

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

For the purpose of an enlarged conceptual representation of the internal architecture of the system, most of the construction allows the use of established graphical 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 the 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 built. At the same time, it is possible not to create separate types of diagrams, if this is not necessary. For example, diagrams and are interchangeable; they are built only for objects with complex behavior. The following table provides guidance on the need to develop (refine) diagrams by system model.

Table 11.6. Linking Models and Diagrams

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

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

4. Give a definition to the concept "".

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 systems based on the OO approach, to organize the relationship of conceptual and software concepts, to reflect the problems of scaling complex systems. Models in UML are used at all stages of the software system life cycle, from business analysis to system maintenance. Different organizations can apply UML as they see fit, depending on their problem areas and technologies used.

A brief history of the UML

By the mid-90s, several dozen OO modeling methods were proposed by various authors, each of which used its own graphical notation. At the same time, any of these methods had their strengths, but did not allow building a sufficiently complete PS model, showing 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 appropriate method, which prevented the widespread use of 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. Buch, D. Rambo and A. Jacobson, who united effort created UML 1.1, which was approved by the OMG in 1997 as a standard.

UML is a language

Any language consists of a vocabulary and rules for combining words to obtain meaningful constructions. So, in particular, programming languages are arranged, such is the UML. Its distinctive feature is that the language dictionary is formed by graphic elements. Each graphic symbol has a specific semantics, so a model created by one developer can be unambiguously understood by another, and also software tool interpreting the UML. From this, in particular, it follows that a PS 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, building the model , we will receive a preparation of the program code corresponding to this model.

It should be emphasized that the UML is a language, not a method. It explains what elements to create models from and how to read them, but it 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 vocabulary

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, cooperation, 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 exploring diagrams.

Relationship show various relationships between entities. The UML defines the following types of relationships:

Addiction shows such a connection between two entities, when changing one of them - independent - can affect the semantics of the other - dependent. Dependency is depicted by a dashed arrow pointing from the dependent entity to the independent entity.
Association Is a structural relationship showing that objects in one entity are related to objects in another. An association is shown graphically as a line connecting the entities being linked. Associations are used to navigate between objects. For example, the association between the "Order" and "Product" classes can be used to find all the goods specified in a particular order - on the one hand, or to find all orders in which there is a given product - on the other. It is clear that the corresponding programs must implement a mechanism for such navigation. If only one direction is required to navigate, it is indicated by an arrow at the end of the association. A special case of an association is aggregation - a relation of the form "whole" - "part". Graphically, it is highlighted with a diamond at the end near the entity-whole.
Generalization Is a relationship between a parent entity and a descendant entity. Essentially, this relationship reflects the inheritance property for classes and objects. The generalization is shown as a line ending with a triangle pointing 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 members and new methods. The UML allows multiple inheritance when an entity is associated with more than one parent entity.
Implementation- the relationship between the entity that defines the specification of behavior (interface) with the entity that defines the implementation of this behavior (class, component). This relationship is commonly used in component modeling and will be described in more detail in subsequent articles.

Diagrams. The UML provides the following diagrams:

Diagrams describing system behavior:

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 a person, 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 can contain classes, use cases, and other entities and diagrams. A package can include other packages to create hierarchies. There are no separate package diagrams in the UML, but they may appear in other diagrams. The package is displayed as a rectangle with a tab.

What the UML provides.

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

And the last ...

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