ITKarma picture

Ave Coder!

You got a cool product idea, but you don’t want to get stuck in the code and lose the whole picture due to small details? Are you about to sit down for the quack of a corporate server and you need to stuff something cool and IT?

This series of articles will be devoted to useful, but sometimes elusive knowledge of young growth - UML diagrams. And I'll start it with a review of existing diagrams, let's talk a bit about history and why there should be so many diagrams.

UML is short for Unified Modeling Language, and as we know, it is a standardized modeling language consisting of an integrated set of diagrams designed to assist system and software developers in identifying, visualizing, constructing, and documenting artifacts of software systems, as well as, for example, for business modeling.

UML is a set of best engineering practices that have proven effective in modeling large and complex systems and is a very important part of the development of object-oriented software.

UML uses mostly graphic notation to express the design of software projects. Using UML helps project teams communicate, explore potential projects, and validate software architectural design.

The Origin of UML


The goal of UML is to provide a standard notation that can be used by all object-oriented methods, as well as select and integrate the best elements of predecessor notations. UML has been developed for a wide range of applications. Consequently, it provides designs for a wide range of systems and activities (for example, distributed systems, analysis, design and deployment of systems).

UML did not arise from scratch, it was preceded by several significant events, personalities and methodologies. For example:

  • OMT object modeling technique [James Rumbaugh 1991], which was the best for analyzing information systems with a large amount of data.
  • Booch [Grady Booch 1994] - great for development and implementation. Grady Butch worked a lot with the Ada language and was a major player in developing object-oriented methods for the language. Although Buch’s method was strong, the notation was perceived less well, for example, cloud forms prevailed in his models, which didn’t look very neat.
  • OOSE (Object Oriented Software Engineering [Ivar Jacobson 1992]) - a model known as the use-case model - is a powerful methodology for understanding the behavior of the entire system, an area where OOP has traditionally been weak.

In 1994, Jim Rambo was not to be confused with John Rambo, although Jim was also cool because he was, for a moment, the creator of the above object modeling technique, stunned the software world when he left General Electric and joined Grady Butch in Rational Corp. The purpose of the partnership was to combine their ideas into a single unified method (the working name for the method really was “The Unified Method”).

By 1995, the creator of OOSE, Ivar Jacobson, had also joined Rational, and his ideas (in particular the concept of “use cases”) were included in the new unified method, now called the Unified Modeling Language.

In contrast to the well-known “Gang of Four,” the Rumbo, Butch and Jacobson Team is known as the “Three Amigos.”

Other object-oriented notations have also affected UML:

  • Mellor and Schlaer [1998]
  • Coad and Yourdon [1995]
  • Wirfs Brock [1990]
  • Martin and Odell [1992]

UML also includes new concepts that weren’t in other basic methods at that time, such as extension mechanisms and a language of restrictions.

Why is UML?


As the strategic value of software grew for many companies, the industry was looking for methods to automate the production of software, as well as to improve quality and reduce costs and time to market.

These methods include component technology, visual programming, patterns, and structures.

Companies are also looking for methods to manage the complexity of systems as they scale up.

In particular, they recognize the need to solve repetitive architectural problems such as physical distribution, concurrency, replication, security, load balancing, and fault tolerance.

In addition, although development for the Web simplifies some things, in general, it exacerbates these architectural problems.

The Unified Modeling Language (UML) was developed to meet these needs.

The main goals of UML design:

  • Provide users with a ready-made, expressive visual modeling language so they can develop and share meaningful models.
  • Provide extensibility and specialization mechanisms to expand core concepts.
  • Be independent of specific programming languages ​​and development processes.
  • Provide a formal basis for understanding the modeling language.
  • Encourage the growth of the market for object-oriented tools.
  • Support for high-level development concepts such as collaboration, structures, templates, and components.
  • Integrate best practices.

UML diagrams are divided into two types - these are structural diagrams and behavior diagrams.

ITKarma picture

Structural diagrams show the static structure of the system and its parts at different levels of abstraction and implementation, as well as their relationship. Elements in the structural diagram represent meaningful concepts of the system and may include abstract, real concepts and implementation concepts. There are seven types of structural diagrams:

  • Composite structure diagram
  • Deployment Diagram
  • Package Diagram
  • Profile Diagram
  • Class Diagram
  • Object Diagram
  • Component Diagram

Behavioral diagrams show the dynamic behavior of objects in the system, which can be described as a series of changes in the system over time. And behavioral diagrams include:

  • Activity Diagram
  • Use Case Diagram
  • State diagram
  • Sequence Chart
  • Communication diagram
  • Interaction Overview Chart
  • Timing chart

Now a few words about each of them

Class Diagram


The class diagram is a central modeling technique that is used in almost all object-oriented methods. This diagram describes the types of objects in the system and the various types of static relationships that exist between them.

The three most important types of relationships in class diagrams (actually there are more) are:

An association that represents the relationship between type instances, for example, a person works for a company, the company has several offices.

Inheritance that directly matches inheritance in Object Oriented Design.

Aggregation, which is a form of composition of objects in an object-oriented design.

ITKarma picture

Component Diagram


In the unified modeling language, a component diagram shows how components are connected together to form larger components or software systems.

It illustrates the architecture of software components and the dependencies between them.

These software components include run-time components, executable components, and source code components.

ITKarma picture

Deployment Diagram


A deployment diagram helps simulate the physical aspect of an object-oriented software system. This is a block diagram that shows the architecture of the system as the deployment (distribution) of software artifacts.

Artifacts are specific elements in the physical world that are the result of a development process.

The diagram simulates the run-time configuration in a static view and visualizes the distribution of artifacts in the application.

In most cases, this includes modeling hardware configurations along with the software components on which they are located.

ITKarma picture

Object Diagram


A static object diagram is an instance of a class diagram; it shows a snapshot of the detailed status of the system at a specific point in time. The difference is that the class diagram is an abstract model consisting of classes and their relationships.

However, an object diagram is an instance at a particular moment that is of a specific nature. The use of object diagrams is rather limited, namely to show examples of data structure.

ITKarma picture

Package Diagram


A package diagram is a UML block diagram that shows packages and dependencies between them.

It allows you to display different types of systems, for example, easily simulate a multi-level application.

ITKarma picture

Composite structure diagram


The composite structure diagram is similar to the class diagram and is a kind of component diagram used mainly in modeling the system at the micro level, but it depicts individual parts instead of entire classes. This is a type of static structural diagram that shows the internal structure of a class and the interactions that this structure makes possible.

This diagram may include internal parts, ports through which parts interact with each other or through which class instances interact with parts and the outside world, and connectors between parts or ports. A composite structure is a set of interconnected elements that interact at run time to achieve a goal. Each element has a role in collaboration.

ITKarma picture

Profile Diagram


The profile diagram allows us to create domain-specific and platform-specific stereotypes and determine the relationship between them. We can create stereotypes by drawing forms of stereotypes and associating them with composition or generalization through a resource-oriented interface. We can also define and visualize the meaning of stereotypes.

ITKarma picture

Use case diagram


The use case diagram describes the functional requirements of the system in terms of use cases. In essence, this is a model of the supposed functionality of the system (precedents) and its environment (actors).

Precedents allow us to connect what we need from the system with how the system satisfies these needs.

ITKarma picture

Activity chart


Activity diagrams are a graphical representation of the workflows of phased actions and actions with support for selection, iteration, and concurrency.
They describe the control flow of the target system, such as the study of complex business rules and operations, as well as the use cases and business processes.
In UML, activity diagrams are designed to model both computational and organizational processes.

ITKarma picture

State diagram


A state diagram is a type of diagram used in UML to describe the behavior of systems, which is based on the concept of state diagrams by David Harel. State diagrams show the allowed states and transitions, as well as events that affect these transitions. It helps to visualize the entire life cycle of objects and, thus, helps to better understand state-based systems.

ITKarma picture

Sequence diagram


A sequence diagram models the interaction of objects based on a time sequence. It shows how some objects interact with others in a specific use case.

ITKarma picture

Communication Diagram


Like a sequence diagram, a communication diagram is also used to model the dynamic behavior of a use case. Compared to the sequence diagram, the communication diagram is more focused on showing the interaction of objects, rather than the time sequence. In fact, a communication diagram and a sequence diagram are semantically equivalent and can flow one into another.

ITKarma picture

Interaction overview diagram


The interaction overview diagram focuses on the overview of the interaction management flow. This is a variant of the Activity Diagram where the nodes are interactions or interaction events. The interactions overview diagram describes the interactions in which messages and lifelines are hidden. We can link the “real” diagrams and achieve a high degree of navigation between the diagrams inside the interaction overview diagram.

ITKarma picture

Timing chart


The timing diagram shows the behavior of the object (s) in a given time period. In fact, this is a special form of the sequence diagram, and the differences between them are that the axes are swapped so that time increases from left to right, and life lines are displayed in separate compartments located vertically.

ITKarma picture

ITKarma picture

Why are there so many diagrams in UML?


The reason for this is that you can look at the system from different points of view, because many interested parties will participate in software development, such as: analysts, designers, coders, testers, quality control, customers, technical authors.

ITKarma picture

All these people are interested in various aspects of the system, and each of them requires a different level of detail.

For example, the encoder must understand the design of the system and be able to convert the design into low-level code.

On the contrary, a technical writer is interested in the behavior of the system as a whole and must understand how the product functions.

UML tries to provide the language in such an expressive way that all interested parties can benefit from at least one UML diagram.

For those who are too lazy to read:


Ave !.

Source