Unified Modeling Language (UML)  is a language or notation intended for analysing, describing and documenting all aspects of a software intensive system. It is a further development from OMT  , Booch  , OOSE  and others methods and notations like David Harelís Statecharts  .
UML can be used as a notation for Object Model in analysis and design when the formality of the SDL Object Model is not wanted. With UML you can represent different structures in a consistent and coherent way using object-oriented principles similar to those of SDL.
We use UML when SDL is not appropriate. Because it is less formal it can be used at an early stage to structure and analyse the concepts of an application domain before the functional design is made. In addition, it can be used to supplement SDL in the area of object modeling. SDL, for instance, does not support relations. The Object Models in UML can help you in your way from the description of the informal needs to a formal functional design in SDL.
Class diagrams describe the static structure to a part of a system. The diagram does not only show classes connected by static relationships (associations), but also packages, interfaces, objects and links etc. Specification of behaviour of a classí objects is not supported - this is regarded as part of property modeling and described in terms of functional roles by means MSCs. During design the behaviour of classes will correspond to behaviour of SDL processes and may then be defined by process graphs.
A class describes a set of objects with similar structure, behavior and relationships. Classes are defined by a set of attributes and operations in a class diagram. The class is shown as a rectangle with tree compartments. Both the attribute and operation compartments can be suppressed as shown in Figure 1 .
An attribute describes a range of values that instances of the class may hold. It is defined by a name and a type. Additionally, an attribute can have properties like visibility (to other classes), multiplicity, an initial value and a property-string that indicates property values.
A stereotype is a classification element and is used to indicate a difference in meaning or use between two elements with the same structure.
An object is an instance of a class. In UML an object is represented by a rectangle with one or more compartments (up to four compartments). The top compartment shows the name of the object and the name of the class. The other compartments can be suppressed.
Sets of objects can only be displayed through cardinalities of associations. Cardinality on association ends only tells how many instances that may be associated with a given number of source instances across the given association. It is not possible to specify how many instances a class may have. This can only be done in a note.
In UML many kinds of relationships can be modeled. The main types are shown in Figure 5 .
An association defines a relationship between two or more classes. Binary associations are relationships between exactly two classes and a n-ary association is an association between three or more classes. The association may indicate that the classes communicate, but this is not necessarily true.
An aggregation (also called relation aggregation ) is a specialised association. It is specified by an aggregation association with a hollow diamond. A part in this type of aggregation can participate in several aggregates.
Composition (or " real aggregation ") is a stronger form of aggregation where the parts can not exist without the whole. The parts can only participate in one composite. Composition is shown as an association with a filled solid diamond nearest the class constituing the whole, or alternatively using the graphically nested form. The nested notation for composite aggregation is shown in Figure 6 .
Objects outside the composite can have relations and connections to part objects, and these relations and connections are specific for these objects being part objects. The same relations and connections will not be valid for objects of these classes (here Panel, Door and Controller) used in other situations.
A nested element may have a rolename within the composition, the syntax being " rolename : classname", e.g. APC : Controller in Figure 6 .
Figure 7 shows an example that class A uses class B. The dependency association in the figure below is labelled with a «uses» stereotype. This dependency states that an object of class A requires the presence of an object of class B for its correct implementation or functioning.
A generalisation is a relationship between a more general element and a more specific element. Generalisation is a mechanism for structuring sets of classes with similar properties into general and specialised classes, as shown below in Figure 8 .
It is possible in UML for a specialised class (subclass) to have more than one superclass, while in SDL only one supertype is allowed. Therefore, to achieve a smoother transition between the UML-model and SDL-model, it is recommended not to use multiple inheritance.
A use case diagram shows the relationships among actors and use cases. An actor is a role of an object or objects outside the system that interacts directly with it in a use case. The actor has class-like properties. A use case is an unit of functionality of the system or a class. One physical object may have different roles and therefore be modeled by several actors. There are three types of use case relationships:
Figure 9 shows a use case example from the access control system.
UML sequence diagram shows simple interactions between objects arranged in a time sequence. It shows the objects with their lifeline and the exchange of messages between objects. It may also show the creation of new objects.
The sequence diagram shows if the object is activated with a rectangular lifeline. When an object is not active, just existing, it has a dashed lifeline. An X at the end of the lifeline denotes that the object cease to exist, and can not be activated again.
The lifeline kan be split into two or more concurrent lifelines. Each lifeline corresponds to a conditional branch in the message flow. The separate lifeline can merge together at some later point in time.
Figure 10 shows an example of an interaction between a user and parts of the access control system in UML. Figure 11 show the same interaction in a MSC diagram. In UML you have no timer concept, which means that you have to model a timer explicitly as an object.
A collaboration is a set of objects and relationships in a particular context. Collaboration diagrams are a static construct to show objects and messages involved in accomplishing a purpose or a set of purposes. Since time is not shown as a separate dimension in the collaboration diagram, the message sequences has to be determined by sequence numbers.
Figure 12 below gives an example of a collaboration diagram. The figure shows sending of signals between some objects in the Access Control system when a user wants to enter an access zone.
Collaboration diagrams can be used to illustrate signal/message exchange between objects in the system. In order to simplify the diagram and show all messages that may be passed between the objects, the sequence numbering may be skipped.
A state is shown as a rectangle with rounded corners. The state has one name compartment that may be empty. It may also have a compartment for internal actions. This compartment may be omitted. Figure 13 shows the four types of states in UML.
Internal actions or activities are performed in response to events received while the object is in a state, without changing state. Actions are atomic and non-interruptible, and take an "insignificant" amount of time.
An event is a "noteworthy occurrence" that might trigger a transition. An event has scope within the package it appears in, and may be used in any state diagrams for classes that have visibility inside the package. This means that an event is not local to a single class.
A transition means that an object would leave one state and enter a new state when an event occurs if specified conditions are satisfied. During the transition actions can be performed and messages may be sent.
A component diagram show the structure of the software components. A component is a reusable part that provides the physical packaging of model elements. The diagram show only component types and node types. Instances must be shown in a deployment diagram.
The component diagram consists of components connected by dashed-arrow dependency relationships or by physical containment representing composition relationship. Figure 14 shows a component diagram of the Access Control System.
Deployment diagrams show the configuration of run-time processing elements and the software components, processes and objects that lives on them. Components that donít exist as run-time entities are not shown in the deployment diagrams.
A node is a run-time physical object that represents a processing resource. This includes computing devices as well as human resources or mechanical processing resources. Nodes may be represented as type and as instances. A node can contain component instances, which indicates that the components lives or runs on the node. Components in a deployment diagram may contain objects. Dashed-arrow dependencies connects components in the deployment diagram.
The deployment diagram shows nodes that are connected by communication associations. Migration between nodes or components can be shown with help of the dependency relationship and the stereotype «becomes». Figure 15 shows a deployment diagram.
The main model structuring mechanism in UML is the package element. A package is a grouping of model elements, like classes, objects, associations, use cases, packages etc. Elements inside a package is owned by the package. The package define a name scope for the elements it contains and all the elements inside a package must have unique names. A package can be basis for storage, access and configuration control.
An example of a package is shown in Figure 16 . In the figure below the dashed arrow indicates that model elements in package AccessPoint uses or are related in some way to model elements in package CentralUnit.
In UML it is, as with OMT, difficult to explicitly show communication between entities in the system. One way to show communication between two classes is to use the navigability association between the communicating classes. The disadvantage is that you can not see the type of messages that can be passed between the classes.
To show all signals/messages that are communicated you can use collaboration diagrams without sequence numbering. This way you get a sketch over the signals in the system. The disadvantage with the collaboration diagram is that you can only see objects in the system not classes.
This section explain the use of UML in TIMe by means of an example for both domain analysis object modeling and design object modeling applied to the Access Control System example. For a short introduction to the example, see First Introduction to the example .
The main objective of domain object modeling is to improve understanding and communication by rigorously describing how concepts and phenomena in the domain are related. This is done by defining objects and classes that represent the domain phenomena and concepts. The object model also serves the purposes of
Use cases are used to identify the main system functions. Figure "Use case example of access control system" shows a possible use case for the Access Control System. The use cases are used as a basis to make interactions, that is sequence or collaboration diagrams. Figure "Sequence diagram showing access to an access zone" shows the use case described in Figure 9 as an interaction in a sequence diagram. Figure "A collaboration diagram showing user access" shows the use case in Figure 9 as an interaction in a collaboration diagram.
Contents of objects is only specified if it is a well-established fact in the domain; otherwise it is deferred to design object modeling. If contents of objects is to be specified, then composition can be used in order to specify a tighter part/whole relation than obtained with aggregation.
System analysis involves the system as an object and considers its use environment. A system analysis produces a specification that covers those aspects of a system that are relevant for its external representation and use.
UML is used for this purpose by selecting the system as the primary class and then only consider classes of objects in the environment that the system has relations to or communicates with. Figure 18 is an example. The communication is shown with help of the navigability concept in UML.
Applied to the system as such, aggregation of UML gives the contents specification in Figure 19 . Note that relations and connections are still used, even though we now have individual objects or object sets as endpoints.
This design may be continued. Each access point is designed to contain three objects, one for handling the panel of the access point, one for handling the central unit and one for handling the door. This is specified by using composition, but now applied to the class AccessPoint, see Figure 20 .
Figure 21 and Figure 22 show two statecharts for the AccessPointís Controller class. Figure 21 shows the behaviour of the Controller class at an general level. The state "Validate access code" is a composite state. When the state machine enters this state the state machine "Validate PIN" (shown in Figure 22 ) is activated.
The state machine "Validate PIN" is shown in Figure 22 . Here it is shown explicitly that the signals/messages Authenticate and Authorize are sent to another object, namely the Validation object.