Forging a real-time spec for models

Much has already been written on the topic of applying the Unified Modeling Language to real-time problems, and whether and how UML needs to be extended for this purpose. To this end, the Object Management Group has requested proposals for a standard way of modeling real-time systems using its UML.

The result is a proposed real-time UML specification that opens up the possibility of exploiting the various real-time analysis techniques, such as different kinds of scheduling ability and performance analyses.

These techniques can significantly improve the design of such systems, but they have not been widely used because they require highly specialized expertise that is not readily available. But by defining a standard way of modeling real-time phenomena, the proposed real-time UML profile provides a vendor-neutral facility for integrating analysis tools and UML modeling tools. This combination can then be used to automate the analysis process, so that real-time domain specialists can directly benefit without having to learn the intricacies of the analysis techniques involved.

The proposed standard is flexible, leaving much latitude for modeling real-time systems in ways that are considered most appropriate. This is achieved by allowing a stereotype corresponding to a real-time concept to be applied to a variety of different UML modeling concepts.

Since the profile can be specialized further, it is also extensible, allowing future specialization for dealing with custom situations and newly developed analysis and even synthesis techniques. The ultimate objective of such a standard is to improve on the predictability and reliability of real-time software design, a process that is currently more of an art (a black art, in some cases) than a true engineering discipline.

The real-time UML profile for modeling time and time-related aspects of systems is designed so that real-time software developers could have a standard way of using UML to represent their systems, and models developed under that profile could be analyzed using common formal analysis techniques for analysis of scheduling ability and performance. It allows the construction of predictive UML models; that is, models that can be used to compute key system properties-such as responsiveness, scheduling ability and resource requirements-before the system is actually constructed. This means providing modelers with the capability to attach quantitative information to a UML model in standard ways so that it can be shared between model editing tools and model analysis tools.

The real-time UML profile automates, as much as possible, the formal analysis of such models by a process. Modelers construct UML models of their systems that include supplementary annotations required by different kinds of model processors. A given model may be analyzed from multiple viewpoints. Furthermore, some tools may even automatically synthesize parts of the user-defined model, thereby ensuring optimality of the design.

Analysis tools
|The annotated model is then transferred to the model-processing tools where it is analyzed (or synthesized) and the results fed back to the model editor. The standard defines both the format and the semantics of such annotations so that models can be exchanged among any tools that comply with the standard.

Each analysis tool automatically transforms the UML model into the internal form required by its analysis method. Consequently, the details of analysis algorithms and internal semantic representations remain hidden from the modeler, who does not have to be an expert on the analysis method. This is quite important, since the technical intricacy of current analysis methods has been one of the biggest impediments to their more widespread use.

A salient characteristic of most real-time software is that both its physical and its logical aspects are important. While the logical part of the specification determines a system's operational (functional) correctness, the physical properties can have an equally significant impact on its validity because real-time systems have definite quantitative constraints, such as response time requirements, which are ultimately dependent on the physical attributes of the underlying implementation technologies.

The physical aspect of software is traditionally represented through the notion of a resource. It reflects, either directly or indirectly, the finite nature of the underlying environment. Note that resources in software systems do not necessarily have to be physical devices. In addition to components such as processors and networks, the concept encompasses logical devices such as buffers and virtual circuits. However, there is always some physical underpinning to every logical device.

In our real-time UML model, a resource is viewed as a server that provides one or more services to its clients. The physical limitations of a resource are represented through its quality-of-service attributes. In general, QoS attributes characterize how well a resource service is performed or how well it needs to be performed.

QoS attributes can be used to model many different properties. They are mostly quantitative (for example, size, service time, capacity), but may also be qualitative specifications that ultimately have a quantitative impact. For example, the scheduling policy of a system (for example, earliest deadline first) is a QoS characteristic of the scheduler of a system that may have fundamental consequences on the scheduling ability characteristics of a system.

Understanding the relationship between a resource and its clients is essential in any quantitative analysis technique. Of course, it is not enough to know only what QoS a resource can offer, but also what its clients demand.

This suggests differentiating the notions of offered QoS (on the resource side) and required QoS (on the client side). The analysis problem then typically reduces to a comparison of these two sets of values; that is, does the supply meet the demand. Naturally, since resources are often shared in software systems, there can be complex interference patterns between clients competing for the same resources so that very sophisticated analysis techniques are required.

Modeling diverse resources
The real-time UML proposal allows the modeling of many different kinds of resources. Specifically, it provides several different categorizations of resources. Thus, based on the functionality of the resource, the proposal defines the following basic categories: processor resources, which represent either virtual or physical processing devices capable of storing and executing program code; communication resources, whose primary purpose is to provide communications between other resources; and general devices, which cover all other types of resources such as disks, physical sensors, motors, etc.

Depending on whether a device is capable of autonomously initiating events, resources are classified as active resources, which can generate stimuli without being prompted by an explicit stimulus within a scenario, and passive resources, which cannot generate their own behavior but only respond when prompted by a stimulus from an executing scenario.

Finally, based on whether a device has some kind of protection against concurrency conflicts or not, resources are divided into either protected resources, which are resources that offer one or more exclusive service instances (services that restrict concurrent access according to some access-control policy); and unprotected resources, whose services are not subject to any access restrictions.

The UML standard does not impose any restrictions on the modeling of time. It neither assumes that time is discrete or continuous, nor that there is a single source of time values in a system. This semantic flexibility, which allows different representations of time, is retained in the profile. Physical time in the UML proposal is assumed to progress monotonically and only in the forward direction.

See related chart