• +7 (812) 318-74-32
  • Новолитовская ул., дом 15Д, оф. 645
  • Понедельник-Пятница 9:00-18:00

The Unified Modeling Language is a standard tool for creating visual models of information systems. The Unified Modeling Language is used to visualize, specify, construct, and document elements of these systems.

UML modeling is suitable for all systems: beginning from information systems within enterprise to distributed Web applications, and even real-time embedded system. This is a very expressive language that allows considering a system from all point of view related to its development and subsequent development. In spite of the abundance of expressive possibilities, the language is simple to understand and use. It is most convenient to start the study of UML with conceptual model, which includes three main elements: basic building blocks, rules defining how these blocks can be combined with each other, and some general language mechanisms.

UML is a component of the development process of information systems. Although UML doesn’t depend on modulated reality, it is best to apply it when the modeling is based on the precedents of use, is iterative and incremental, and the system has a distinct architecture.

UML is a language for visualizing, specifying, constructing, and documenting the element of software systems. The language consists of vocabulary and rules that allow combining its component words and get meaningful design. In the modeling language the vocabulary and rules focus on conceptual and physical representation of the system. A modeling language like UML is a standard tool for creating visual models of information systems.

While creating an information system of any complexity modeling of the future system is conducted, but in many cases this is done informally, without the development of any document. However, such an approach can lead to troubles. First, the exchange of views on the conceptual model is only possible when all participants speak the same language. Secondly, it is impossible to get the idea about certain aspects of information systems without a model that goes beyond the textual programming language. Thirdly, if the author of the code never write down models designed by him, this information will be lost forever, if he change the job. At best it can be only partially re-created relying on the implementation.

The usage of UML allows us solving the third problem: explicit model facilitates communication.

It is best to model some features of the system in the form of the text, while others graphically. In fact, in all interesting systems there are structures that can not be represented using only programming language. UML is a graphical language that allows us solving the second of the indentified problems.

UML is not just a set of graphic symbols. Each of them uniquely reflects its meaning. Model, written by one developer, can be unmistakably interpreted by another, or even by a program. The first of the above problems is solving thus.

In this context, “specifying” means the construction of accurate, unmistakable, and complete models. UML allows specifying all significant decisions regarding analysis, design and implementation, which should be taken within the development and the deployment of information systems.

UML is the language of visual design, and models created with its help can be directly interpreted into different programming languages.

While information system developing, following elements are created among others:

  • System’s requirements;

  • A description of architecture;

  • Project;

  • Source code;

  • Project plans;

  • Tests;

  • Prototypes;

  • Versions, etc.

Depending on the accepted methods of development the execution of some works is more formal than others. Mentioned elements are not just delivered components of the project; they are necessary for managing, for assessing the result, and also as a mean of communication between team members during the system development and after its deployment.

UML allows solving a problem of system architecture and all its parts documenting, offering a language for formulation of system requirements and definition of tests, and, finally, provides means for works modeling on the stage of project planning and versions’ managing.

Where is UML used?

Unified Modeling Language is primarily intended for information systems development. Its usage is particularly efficient in the following areas:

  • Information systems enterprise-wide;

  • Banking and financial services;

  • Telecommunications;

  • Transportation;

  • Defense industry, aviation and aerospace;

  • Retail business;

  • Medical Electronics;

  • Science;

  • Distributed Web-systems.

The UML scope is not restricted to software modeling. Its visual expressiveness makes it possible to model, for example, flow of documents in legal systems, a structure and functioning of patient care in hospitals, to design hardware.

Conceptual Model of UML

To understand the UML it is necessary to learn its conceptual model, which includes three parts: basic building blocks of the language, the rules of their combination and some mechanisms common to all the language. Having learned these items, you will be able to read UML models and create your own models – not very complicated at first, of course. As you gain experience in dealing with the language you will learn to use its more advanced features.

UML building blocks

There are three types of UML building blocks:

  1. entities;

  2. relations;

  3. diagrams.

Entities are abstractions which are main elements of the model. Relations connect different entities; diagrams group together entities of interest.

  1. Four types of entities in UML:

  1. structural;

  2. behavioral;

  3. grouping;

  4. annotative.

Entities are basic object-oriented blocks of the language. They help to create valid models.

  1. There are seven types of structural entities:

  • Class

  • Interface

  • Collaboration

  • Use case

  • Active class

  • Component

  • Node

These seven basic elements – classes, interfaces, collaboration, use case, active classes, components, and nodes are basic structural entities, which can be included in the UML model. There are also variations of these entities: actors, signals, utilities (types of classes), processes and threads (types of active classes), applications, documents, files, libraries, pages, and tables (types of components).

  1. Behavioral entities are dynamic components of the UML model. They are verbs of the language: they describe the behavior of the model through time and space. There are only two basic types of behavioral entities:

  • Interaction

  • State machine

They are major behavioral entities included in the UML model.

  1. Grouping entities are organizing parts of the UML model. They are blocks on which the model can be decomposed. There is only one primary grouping entity, namely the package.

Packages are the basic grouping entities with the help of which the UML model can be created. There are also variations of packages, such as Frameworks, Models and Subsystems.

  1. Annotative entities represent an explanatory part of the UML model. They are comments for additional description, explanations or comments on any item of the model.

There is only one basic type of annotative entities – Note. A Note is just a symbol to depict comments or restrictions attached to an element or a group of elements. The Note is presented by rectangle with a curved edge that contains textual or graphical comment.

  1. There are four types of relations defined in UML:

  • dependency;

  • association;

  • generalization;

  • realization.

These relations are the basic building blocks for connecting in UML and are used to create valid models. Four mentioned elements are the main types of relations that can be included in the UML model. There are also their variations, for instance Refinement, Trace, etc.

  1. The Diagram in the UML is graphical representation of a set of elements, most commonly depicted as linked graph with vertices (entities) and edges (relations). Diagrams are drawn to visualize systems from different points of view. A Diagram in some sense is one of projections of the system. As a rule, except the most trivial cases, diagrams give minimized representation of the elements that make up the system. The same element may be present in all diagrams, or only in a few (the most common variant), or not be present in any (very rare). In theory, diagrams can contain any combinations of entities and relations. In practice, however, a relatively small number of standard combinations is used which correspond to five most common types constituting the information system architecture.

Thus, nine types of diagrams are distinguished in the UML:

  • Class diagram;

  • Object diagram;

  • Use case diagram;

  • Sequence diagram;

  • Interaction diagram;

  • State diagram;

  • Activity diagram;

  • Component diagram;

  • Deployment diagram.

Here is a partial list of diagrams used in UML. Tools allow generating other diagrams, but nine listed above diagrams occur in practice more often.

ULM rules

UML building blocks can not be randomly combined with each other. Like any other language, UML is characterized by a set of rules defining how a well designed model should be look like, which is in harmony with all the models, which are associated with it.

There are semantic rules in UML that allow correctly and clearly identifying:

  • Names which can be given to entities, relations and diagrams;

  • Scope (the context in which the name has some significance);

  • visibility (when the names are visible and can be used be other elements);

  • integrity (how elements must be properly and consistently relate to each other);

  • implementation (what means to perform or imitate some dynamical model).

Models created within the process of information systems development evolve over time and can be uniquely considered by various participants of the project at different periods of time. Because of this reason not only well drawn models are created, but also those which:

  • contain hidden elements (a number of element are not shown to simplify the perception);

  • incomplete (some element are omitted);

  • inconsistent (the integrity of the model is not guaranteed).

The appearance of the not enough well drawn models is inevitable within the development process until not all details of the system are fully clarified. The UML rules encourage, though not require, solving the most important questions of analysis, design and implementation while working on the model, resulting in a well drawn models over time.

Common UML mechanisms

Modeling becomes more simply and effective if one follows some of the agreements. Following specific architectural patterns, building can be designed in a Vicinity or French style. The same principle is applied with respect to UML. A work with this language is significantly facilitated by using of common mechanisms, listed below:

  • Specifications;

  • Adornments;

  • Common divisions;

  • Extensibility mechanisms.


To visualize, specify, design and documentation of information systems it is necessary to consider them from different perspectives. All those involved in the project – ultimate users, analysts, developers, system integrators, testers, technical writers and projects managers – pursue their own interests, and everyone is looking on the created system variously at different moments of her life. The system architecture is perhaps the most important element that is used to control all possible points of view and thus contributes to iterative and incremental development of the system throughout its life cycle.

Architecture is a set of significant decisions concerning:

  • Organization of a software system;

  • Selection of structural elements that make up the system, and their interfaces;

  • The behavior of these elements specified in cooperation with other elements;

  • Composing from these structural and behavioral elements of more and more large subsystems;

  • An architectural style that guides and defines the entire organization of the system: static and dynamic elements, their interfaces, cooperation and the way of their integration.

The architecture of a software system includes not only structural and behavior elements, but also usage, functionality, performance, flexibility and possibilities of iterated use, completeness, economic and technological constrains and compromises, as well as aesthetic issues.

Use case view covers use cases that describe the behavior of the system observed by ultimate users, analysts and testers. This view specifies not the real organization of the software system, but those driving forces that affect the formation of the system architecture. In UML, the static aspects of this view are represented by use case diagrams, and dynamic aspects – by interaction, state and activity diagrams.

Design view includes classes, interfaces and cooperation, forming the vocabulary of the problem and its solution. This type supports primarily functional requirements to the system; those services that it must provide to ultimate users. With the help of UML static aspects can be transmitted by classes and objects diagrams, and dynamic aspects – by interaction, state, and activity diagrams.

Process view includes threads and processes that form mechanisms of parallelism and synchronization in the system. This type describes mainly the performance, scalability and capacity of the system. In UML, its static and dynamic aspects are rendered by the same diagrams as for the design view, but special attention is paid to active classes, which represent corresponding threads and processes.

Implementation view coves components and files used to build and release the final software product. This type is intended primarily for the configuration management of the system versions, compiled from independent (for some extent) components and files that can be combined in different ways with each other. In UML, static aspects of this type are represented by component diagrams, and dynamic – with the help of interaction, state and activity diagrams.

Deployment view comprises nodes that form the topology of the system’s hardware, on which it runs. It is primarily related to the distribution, supply and installation of parts that make up the physical system. Its static aspects are described by deployment diagrams, and dynamic aspects – by interaction, state and activity diagrams.

Each of listed types can be considered completely independent, so that persons related to the development of a system can focus on studying only those aspects of architecture, which directly affect them. But we must not forget that these types interact with each other. For example, the nodes from the deployment view contain the components, described for implementation view, and those in turn are the physical embodiment of classes, interfaces, cooperation, and active classes from design and process views. The UML allows displaying each of five listed types and their interactions.