Unified modeling language

UML diagram collage.

The Unified Modeling Language (UML) is the language for modeling information systems. software most known and used today; is endorsed by the Object Management Group (OMG).

It is a graphical language for visualizing, specifying, building, and documenting a system. The UML offers a standard for describing a "blueprint" of the system (model), including conceptual aspects such as processes, system functions, and concrete aspects such as programming language expressions, database schemas, and recycled compounds.

It is important to note that UML is a "modeling language" to specify or to describe methods or processes. It is used to define a system, to detail the artifacts in the system, and to document and build. In other words, it is the language in which the model is described.

A variety of software development methodologies (such as the Rational Unified Process, Rational Unified Process or RUP) can be applied in software development, but does not itself specify which methodology or process to use.

UML cannot be compared with structured programming, since UML means Unified Modeling Language, it is not programming, it only diagrams the reality of a use in a requirement. While structured programming is a way of programming as object-oriented is, object-oriented programming has been a perfect complement to UML, but that's not why UML is taken only for object-oriented languages.

UML has several types of diagrams, which show different aspects of the represented entities.

UML Standardization

Since 2004, UML has been an ISO-approved standard as ISO/IEC 19501:2005 Information technology — Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.2.

In 2012 the standard was updated to the latest final version available at that time, 2.4.1, giving rise to the ISO/IEC 19505-1 standards

History

Before UML 1.x

After the Rational Software Corporation hired James Rumbaugh from General Electric in 1994, the company became the source of the two most popular object-oriented modeling schemes of the time: Rumbaugh's Object-Modeling Technique (OMT) which was better for object-oriented analysis, and the Booch Method (by Grady Booch) which was better for object-oriented design. They were joined soon after by Ivar Jacobson, the creator of the object-oriented software engineering method. Jacobson joined Rational in 1995 after his company Objectory AB was purchased by Rational. The three methodologists were known as the Three Amigos, because they were known for their constant discussions about methodological practices.

In 1996 Rational concluded that the abundance of modeling languages was encouraging the adoption of object technology, and to move toward a unified approach, they commissioned the Three Amigos to develop a "unified modeling language" open. Representatives of competing companies in the area of object technology were consulted during the OOPSLA '96; they chose "boxes" to represent classes instead of Booch's notation which used "clouds" symbols.

Under the technical direction of the Three Amigos (Rumbaugh, Jacobson and Booch) an international consortium called UML Partners was organized in 1996 to complete the UML specifications, and to propose it as a response to the OMG RFP. The UML Partners draft UML 1.0 specification was proposed to the OMG in January 1997. During the same month, the UML Partners formed a Semantic Task Force, headed by by Cris Kobryn and managed by Ed Eykholt, to finalize the semantics of the specification and to integrate it with other standardization efforts. The result of this work, UML 1.1, was submitted to the OMG in August 1997 and adopted by the OMG in November 1997.

UML 1.x

As a modeling notation, the influence of the OMT dominates the UML (for example, the use of rectangles for classes and objects). Although the "clouds" Booch's ability to specify design details at lower levels was adopted. The "Use Cases" The Objectory and Booch's component notation were integrated into the rest of the notation, but the semantic integration was relatively weak in UML 1.1, and wasn't really fixed until the UML 2.0 major revision.

Concepts from many other object-oriented (MOO) methods were loosely integrated into the UML for the purpose of making it compatible with all MOOs. In addition, the group took into account many other methods of the time, with the aim of ensuring wide coverage in the domain of real-time systems. As a result, the UML is useful for a wide variety of engineering problems, from simple processes and single-user applications to concurrent and distributed systems.

UML 2.x

UML has matured considerably since UML 1.1, several minor revisions (UML 1.3, 1.4 and 1.5) have fixed defects and bugs from the first version of the UML. These have been followed by the major revision UML 2.0 which was adopted by the OMG in 2005.

Although UML 2.1 was never released as a formal specification, versions 2.1.1 and 2.1.2 appeared in 2007, followed by UML 2.2 in February 2009. UML 2.3 was officially released in May 2010. UML 2.4. 1 was officially released in August 2011. UML 2.5.1 was released in October 2012 as an "In Progress" who was formally released in June 2015.

Types of diagrams in UML 2.5

There are two main kinds of diagram types: structural diagrams and behavioral diagrams. The latter include several that represent different aspects of interactions. These diagrams can be hierarchically categorized as shown in the following class diagram:

Structural

Structural diagrams show the static structure of the system and its parts at different levels of abstraction. There are a total of seven types of structure diagrams:

Class diagram

Class diagrams are by far the most widely used type of UML diagram. It is the main building block of any object-oriented solution. It shows the classes in a system, attributes and operations of each class, and the relationship between each class. In most modeling tools, a class has three parts, name at the top, attributes in the middle, and operations or methods at the bottom. In large systems with many related classes, the classes are grouped together to create class diagrams. The different relationships between the classes are shown by different types of arrows.

Component diagram

A component diagram shows the structural relationship of the components of a software system. These are mainly used when working with complex systems that have many components. Components communicate with each other through interfaces. Interfaces are linked by connectors.

Deployment Diagram

A deployment diagram shows your system's hardware and the software on that hardware. Deployment diagrams are useful when the software solution is being deployed to multiple computers, each with a particular and unique configuration.

Object Diagram

Object diagrams, sometimes called instance diagrams, are very similar to class diagrams. Like class diagrams, they also show the relationship between objects, but use real-world examples. They are used to show what a system will look like at a given time. Because data is available on objects, it is often used to explain complex relationships between objects.

Package diagram

It is the Unified Modeling Language that represents the dependencies between the packages that make up a model. That is, it shows how a system is divided into logical groupings and the dependencies between those groupings.

Since a package is normally thought of as a directory, package diagrams provide a breakdown of the logical hierarchy of a system

Profile diagram

Profile Diagram is a new type of diagram introduced in UML 2. This is a type of diagram that is rarely used in any specification.

Composite Structure Diagram

Composite structure diagrams are used to show the internal structure of a class.

Behavioral

They show the dynamic behavior of objects in the system.

Activity diagram

Activity diagrams represent workflows graphically. They can be used to describe the business workflow or the operational workflow of any component of a system. Sometimes activity diagrams are used as an alternative to state machine diagrams.

Use Case Diagram

As the best-known type of UML diagram, use case diagrams provide an overview of the actors involved in a system, the different functions needed by those actors, and how these different functions interact. It is a great starting point for any project discussion, as the main stakeholders and system processes can be easily identified.

State machine diagram

State machine diagrams are similar to activity diagrams, although the annotations and usage differ slightly. Sometime they are known as state diagrams or state diagram diagrams as well. These are very useful for describing the behavior of objects that act differently depending on the state they are in at the moment.

Interaction Diagram

Interaction diagrams include different types of diagrams:

Sequence Diagram

Sequence diagrams in the UML show how objects interact with each other and the order in which those interactions occur. It is important to note that they show the interactions for a particular scenario. Processes are represented vertically and interactions are shown as arrows. UML sequence diagrams are part of a UML model and only exist within UML modeling projects.

Communication diagram

The communication diagram was called the collaboration diagram in UML 1. It is similar to sequence diagrams, but the focus is on messages passed between objects.

Timing diagram

Timing diagrams are very similar to sequence diagrams. They represent the behavior of objects in a given time frame. If it's just one object, the diagram is straightforward, but if more than one object is involved, they can also be used to show object interactions over that time period.

Global diagram of interactions

General or global interaction diagrams are very similar to activity diagrams. While activity diagrams show a sequence of processes, interaction diagrams show a sequence of interaction diagrams. In simple terms, they can be called a collection of interaction diagrams and the order in which they happen. As mentioned above, there are seven types of interaction diagrams, so any one of them can be a node in an interaction overview diagram.