Using UML to Describe and Analyze Quality of Service

The UML provides an excellent starting point for defining and designing computer systems, but for real-time development, the UML needs to go further. Recognizing this need, in 1999 the Object Management Group (OMG) spawned a new initiative, the Real-time Analysis and Design Group (RTAD), specifically to recommend UML extensions in the area of real-time development.

The goal of the RTAD initiative is, "to issue a comprehensive set of RfPs (Requests for Proposal) leading to OMG standards that will support the use of object-oriented approaches in the analysis, design, and development of real-time computing systems." There have been three RfPs discussed within the RTAD:

1. UML Profile for Scheduling, Performance, and Time
2. UML Profile for Quality of Service (QoS) other than timeliness (draft RfP)
3. UML Profile for large-scale, distributed systems (no RfP as yet)

This article will describe in more detail the Request for Proposal (RfP) for a UML Profile for Scheduling, Performance, and Time, issued by the RTAD in 1999.

The request for a UML profile on Scheduling, Performance, and Time was the first—and so far the only—RfP the RTAD has issued. This RfP aims to plug a significant hole experienced by real-time UML users. The RFP solicits proposals for a UML profile that defines standard paradigms for modeling time-, schedulability-, and performance-related aspects of real-time systems. An initial submission of a proposed profile was made in September of 2000, and a revised submission in June 2001. The detail of the submission is now reasonably well defined, and so now seems a good time to describe it in detail. This article covers the core of the submission and one specific extension that deals with schedulability analysis.

The Core sub-profile is the basis for everything else in the profile; it consists of:

• The Resources sub-profile which enables the addition of Quality of Service (QoS) to any model element, both descriptors (such as class) and instances (such as object). This sub-profile also includes a model of resources as servers, used by clients, with associated services.
  
  
• The Time sub-profile which describes how to represent time. This sub-profile defines time characteristics and adds these characteristics to core UML concepts, such as action and event.
  
  
• The Concurrency sub-profile which defines concurrency and communication in sufficient depth to represent causality within and between concurrently executing entities.

The two infrastructure sub-profiles that are mandated in the RfP are RT CORBA and Enhanced View of Time, since both are existing OMG infrastructure standards. However, we expect infrastructure providers, such as ORB and O/S vendors, to add their own sub-profiles subsequent to the adoption of this submission.

Schedulability is the most advanced analysis sub-profile so far. It builds on the core, but adds specific capabilities to resources, actions, and events in order to represent the QoS required for calculating worst-case scenarios. There is also a sub-profile for more general performance analysis.

Figure 1 also shows two examples of how the profiles might be used: the modeler might choose to incorporate elements from both the infrastructure and the analysis technique they're using and combine them in their model. If a particular combination of analysis technique and infrastructure was particularly popular, then you might create a special profile combining both; any modeler that used both could then use this new profile. The following sections describe the detailed content of the profiles.

The principal extension mechanisms are:

• Tag Definition—used to specify new kinds of properties that may be attached to model elements. The actual properties of individual model elements are specified using Tagged Values. These may be either simple data type values or references to other model elements.
  
  
• Stereotype—a model element that defines additional values (based on tag definitions). Any model element may be branded by one or more particular stereotypes. In this case, the model element receives the tag values of the stereotypes in addition to the attributes, associations and super classes that it has in the standard UML.
  
  
• Profile—a stereotyped package that contains model elements that have been customized for a specific domain or purpose by extending the UML metamodel using, primarily, stereotypes and tag definitions.

The underlying model of resources is a client/server model; resources can be thought of as servers with offered QoS, such as the length of time required to acquire and release the resource. At a more detailed level, resources offer services, often represented as operations in UML; services also offer QoS, such as response time. Resource users—known as resource clients—have required QoS, such as deadlines for service completion.

A good example of a resource is a semaphore, which offers services, 'get' and 'put' that acquire and release the resource. A counting semaphore has a 'capacity' quality of service, which denotes the maximum number of concurrent users.

The submission also adds fundamental timing patterns of different kinds that are essential in supporting schedulability and performance analysis. These patterns include modeling whether an event recurrence is periodic or not and, in the former case, also includes the modeling period, distribution functions, and jitter.

A procedure is the root of an action sequence, an ordered set of actions, some of which contain other action sequences. In this case, causality can be defined using these ordered collections of actions at ever-deeper levels of nesting. A concurrent unit is an entity, such as an object, with one main procedure, also known as a thread, which executes concurrently with those of all other concurrent units.

Causality between procedures is defined by the use of communication primitives. If a class offers a service, this indicates that the class will provide at least one procedure that handles a request for that service (use of mechanisms such as inheritance may result in more than one). A message action is a specific type of action that requests a service by sending a message to an object of the class offering that service. Once it is received, the message is hooked into the appropriate handler. Although there may be multiple potential handlers for a service request at the descriptor (class) level, there will only be one at the instance (object) level, providing a causal link between the procedure issuing the message action and the handling procedure.

There are two choices at either end of the communication, which affect the detailed causality between concurrent threads of control. At the server end, the service request may either be handled immediately or deferred. In the immediate case, a further property describes whether the object creates its own thread to execute the handling procedure, or assumes that there is an existing thread available. At the client end, the message action may either represent an asynchronous or synchronous invocation of the service. If the request is asynchronous, then the client proceeds immediately; if the request is synchronous, then the client waits for a response before continuing.

Figure 2 shows a sequence diagram that has been annotated with several stereotypes from the core profiles. Stereotypes are indicated using guillemets («») while tag values are listed in braces after the stereotype indication. Each profile provides a different stereotype prefix: "GRM" for Resources, "RT" for Time, and "CR" for concurrency.

'SensorData' is a resource supporting a number of services. 'StartStorage' is stereotyped «GRMacquire» because it acquires the SensorData resource. 'StopStorage' is stereotyped «GRMrelease» because it causes the resource to be released. Finally, there is 'CreateItemData', which can afford to be non-exclusive if bracketed by resource acquisition and release.

'TelemetryGatherer' is a concurrent unit («CRconcurrent») whose main thread processes the 'TelemDataGather' timeout. The 'main' procedure simply waits for the timeout, which occurs periodically at 100ms intervals.

Many of the communication actions that access resources are synchronous. Thus you have the stereotype «CRsynch», with the resource handling the requests immediately on a remote thread, and «CRimmediate» {CRthreading=remote}. This corresponds to the semantics of a standard procedure call or RPC.

The actions and events (as appropriate) have been given time annotations. These annotations are durations in the case of actions, such as for "UnPackData" and "main" itself, and times for the events, such as {RTat='periodic''100'} for the "TelemDataGather" event. Note that event timestamps are often not simple values, but may be periodic or statistical distributions.

The Schedulability sub-profile particularly focuses on systems having hard timeliness requirements and how to annotate the model in ways that allow a wide variety of schedulability techniques to be applied. The goal is, of course, to make it possible to determine whether or not a model is schedulable—if it will be able to meet its guaranteed response times. This is the most developed of the analysis sub-profiles. While this sub-profile is particularly intended to support modelers who wish to analyze hard real-time constraints, it will also handle soft real-time constraints.

The key concepts in schedulability analysis are:

• A Schedulable Entity, which represents a load on the system. It consists of an initiator, or trigger, and a sequence of actions, or response. A trigger specifies its occurrence pattern and deadline while an action specifies its utilization of an Execution Engine (work) and its use of resources.
  
  
• An Execution Engine, which represents the capability of the system to do work. It specifies its scheduling Policy, such as FIFO or Fixed Priority, and such performance attributes such as context switch time and processing rate.
  
  
• A Resource, which represents any resource, other than the Execution Engine, needed by Schedulable Entities while responding to their triggers. It specifies its arbitration policy, such as Priority inheritance, FIFO, and Highest Lockers; whether it is pre-emptable or not; and the setup and access overheads associated with its use.

Figure 3 shows a collaboration diagram, which has been annotated with stereotypes from the schedulability sub-profile, hence the "SA" prefix.

A typical series of analysis steps is:

1. Create a behavioral model, including concurrency, contention, and behavior
2. Include quantifiable characterization of contention, blocking, and execution times
3. Analytically predict worst case response time using Rate Monotonic Analysis (or similar technique).

Typically, the analyst will iterate through the above steps until the analysis predicts an acceptable outcome (typically, that outcome means that all of the deadlines can be met).

You use the stereotypes in the Core sub-profiles during Step 1 to describe the underlying behavior of the system. You then use the «SA...» stereotypes to add the appropriate quantities for Step 2.

The three main objects in the example are «SAschedulable» resources, which correspond to Schedulable Entities, all using an «SAresource», 'SensorData'. There are three events of interest, designated «SAtrigger», each causing specific responses, which run on the 'main' thread of their respective schedulable resources (schedulable resources must be active).

You can calculate the worst-case response time for a response, the key measure of system load. This time comes from the raw execution time (as if the response was being executed on its own exclusive execution engine) combined with the time spent either being blocked waiting for a resource (in this case 'Sensor Data'), or preempted by another higher priority schedulable resource (note the priority attached to the «SAresponse» stereotype). In this case, an analysis has already been performed assuming a single Execution Engine (not shown) and all three triggers have been found to be Schedulable. The worst-case completion time of their respective responses were calculated to be less than the deadline of their triggers.

1. Modeling actual situations using instances—UML has a complete descriptor model (classes, operation, and so on), but not a complete instance model (instances, event occurrences, and the like). The submission suggests that the concept of action execution, in other words, the specific execution of a defined action, be added, but this is just a patch. We need a much more comprehensive solution.
   
   
2. Parameterized models—A given analysis may require many executions of the same scenario, with slightly varying parameters, in order to find an optimal solution. The submission suggests a textual convention to identify parameters and a model post-processor to plug in actual parameter values. However, what is needed is a graphical capability to parameterize composite UML objects, such as package and collaboration, with Quality-of-Service, so a modeler can specify and view parameters within a UML context.

Hopefully, both of these issues will be addressed in UML 2.0.

About the Author Alan Moore is the Vice President for Product Strategy at Artisan Software. Alan has 15 years of experience in the development of real-time and object-oriented methodologies and their applications in a variety of problem domains. He has been actively involved in product development, training, and consulting related to OOAD and structured development tools during that time. Alan has co-authored a book on GUI design, published several papers, and has lectured on a wide variety of analysis and design issues. Alan is responsible for the specification, planning, and management of the ARTiSAN product strategy. He is the author of ARTiSAN "Real-time Perspective," a pragmatic approach to the development of real-time systems, and is an active participant in the Real-time Analysis and Design Group (RTAD) of the Object Management Group (OMG).