Since its emergence in the mid-1990s as a modeling methodology to allow developers to define, specify and analyze software architectures, the Universal Modeling Language has changed dramatically. Now it is becoming a true industry standard capable of satisfying requirements for a wide spectrum of applications and environments.

Once the new standard is approved, UML will be useful not only in defining, partitioning and analyzing software elements and how they work together, but also in modeling both the hardware and software elements in a design and the relationships between them. Additions have made this enterprise-level tool much more useful in a wide range of real-time and deterministic embedded systems. And developers will now be able to use UML to generate the application code from the system defined with the modeling language.

In its evolution, UML owes a lot not only to the developer community but also to many of its predecessors and competitors, in particular applications and segments. These include the Specification Description Language (SDL), developed for the the telecom and networking environment; real-time object-oriented modeling (Room); and real-time UML, as well as other influences such as Message Sequence Charts.

In both SDL and Room, architectural modeling is ascribed much importance, and constructs for supporting this kind of modeling constitute some of the most important proposed improvements to UML. Architectural modeling not only increases the modeler's arsenal but may affect the way systems are developed in that it supports a more component-based approach. But since backward compatibility is a strong requirement, the approach is not forced on users. Further, it should be remembered that UML is not a method; it can be used with most development processes.

The idea of compositional building blocks is at the core of architectural modeling, and the goal is for each building block to model the structure and behavior of a part of the system.

In SDL, the fundamental concept was a state machine that executed within a process. In later revisions, the block concept was introduced to model structural aspects of the system, wherein a block could contain other communicating blocks or processes. In SDL-2000, the latest revision to date, the concepts of block and process have been harmonized into that of an agent that could capture both structure and behavior.

Room, which later evolved into UML-RT, offers a corresponding construct in capsule. One of the characteristics of these building blocks is that they are self-contained, which is reflected by the fact that they are all active, i.e., they have their own thread of control.

This makes it easier to model distributed systems and to assemble the building blocks in different ways. Each building block can thus be viewed as a complete system by itself or can be used as a small part of a system. In UML 2.0, active classes are used to model agents and capsules.

Interfaces play an important role in component-based design; the ordinary interface concept of UML is still supported but is called a "provided interface" in UML 2.0. To complement it, the concept of a "required interface" is added. Just as the provided interface defines the services that are implemented by a class, a required interface defines the services that the class needs in order to function properly.

Class development
This way, it is possible to develop a class as a standalone entity whose environment is specified solely through interfaces. The concepts of provided and required interfaces are derived from SDL and provide the basis for supporting protocol roles and protocols in UML-RT, since a protocol role is essentially a combination of a required and a provided interface. Interfaces in UML 2.0 are further expanded to have attributes and to be able to deal with asynchronous communication through the reception of signals.

In both SDL and UML-RT the concept of an interaction-called a gate in SDL and a port in UML-RT-plays a prominent role. In UML 2.0, the port is simply typed by an interface and can be either required or provided. A port sits on the boundary of a class and can be viewed either from inside the class (white-box view) or from outside the class (black-box view). In the former case it represents a view of the environment of the class; in the latter it represents a view of the class as seen from the environment.

The primary purpose of a port, however, is to act as a connection point when classes are connected to each other as parts of an internal structure. In that regard, it can be viewed as a role that is played by the class in a particular interaction.

A composite port comprises a collection of required or provided ports and is used to model when a port is typed by multiple interfaces or when a port should support bidirectional communication. The latter occurs when a composite port has both required and provided ports. Ports are usually named by their typing interfaces, but composite ports have to be given a name of their own.

So far, we have been talking only about the definition of classes. We next get to how each class can have an implementation that is made up of an internal structure that may be coupled to a behavior. In the simplest case, the implementation of a class is given directly by a behavior such as a state machine. In more complex cases the (containing) class may have an additional internal structure, which is made up of classes that are used as parts of the containing class and connected with each other in accordance with their ports and interfaces. Only classes that have matching interfaces may be connected to each other.

A part in UML 2.0 represents a usage of a class in a specific context; the same class can be used differently within other contexts or may even define other parts within the same context. A connector is used to indicate legal communication paths between parts. The paths can be considered contextual associations, since they are only applicable within the internal structure in which they are defined. We earlier talked about compositional building blocks; when an instance of a class is created, instances will also be created for each part in its internal structure according to the multiplicity of the part.

Likewise, when the instance of the containing class is terminated, each contained instance is also terminated. During the lifetime of an instance of a class, its contained instances may be dynamically created and terminated according to its multiplicity.

Both SDL and UML-RT allow you to decompose agents and capsules into internal structures. In SDL, the internal structure comprises a number of instance sets, whose gates may be connected through channels, whereas UML-RT relies on collaborations where the ports of subcapsules may be connected through connectors.

It is possible to mix behavior and structure as part of the internal structure. This is reflected among the ports of a class, where behavioral ports that connect directly to the behavior of the class are distinguished from ports that connect to the parts of the class.

Normally, the behavior of an active class is expressed through a state machine, but it is also possible to use an activity, for example. Because of the life cycle dependency between the internal structure and the containing class, there is always some implicit behavior attached to a class, but an explicit behavior can be used to dynamically control the creation and termination of part instances or to handle communication between the containing class and its parts.

In UML-RT, a behavioral port corresponds to an end port, while other ports are relay ports. SDL does not distinguish between gates that connect to the internal structure and gates that connect to the behavior of the agent.

The contribution from SDL does not stop at the structural constructs described above; it also affects the definition of behavior. At a coarse-grained level, it is easier to deal with scalable state machines, where entry and exit points can be used to determine execution routes through a particular state.

At a more fine-grained-but far more important-level, the addition of a semantics for the UML is largely inspired by the way SDL goes from being a pure specification language to being used as a programming language. The action semantics precisely define the semantics of executing such actions as assignments, loops and decisions as part of, for example, state machine transitions. Given appropriate transformation rules, it is possible to swiftly change an implementation from one programming language to another.

See related chart