UML 1.4 includes no support for real-time, but a profile for Scheduling Performance and Time (called SPT profile) had been defined, including some extensions for the expression of timing properties, mainly in the form of tag values. We have defined a real-time profile that respects the SPT profile, which takes over most of its basic concepts, defines a concrete syntax where this is missing and specifies the usage. Also, contrary to the SPT where time constraints are mainly expressed at instance level, the Omega real-time profile enables time constraints at class level:
- We have introduced the notions of timer and clock, as they exist in other modelling formalism and as they have been introduced in UML 2.0. Timers can be set and deactivated and cause a "timeout event" after a specified duration and clocks can be set and deactivated, and when active, they count the duration since they have been set for the last time. This allows the definition of time dependent behaviour by means of new primitives in the action language.
- We provide syntactic access to semantic level events. A semantic level event is a state change in the underlying dynamic semantic. Each syntactic construct may have to 0, 1 or more semantic level events associated. With a state of an enter and an exit event is associated, with a signal transmission, a send, a receive and a consume event. A syntax is defined for identifying all state changes. An event can be defined as a class stereotyped event with predefined parameters depending on their type (all events have an occurrence time, a send-signal event has a sender, a receiver, a signal type, signal type depending parameters) and possibly user defined attributes. Moreover, there are means to refer to different occurrences of an event in a given execution or prefix of it.
- Expressions of the type duration which can be used in time constraints can be defined simply using arithmetic expressions on clocks and the occurrence time attribute of different events (this is the access to time and duration used in OCL, see below and in observers, see next item), by a set of predefined duration expressions.
- Time constraints may be arbitrary Boolean expressions depending on time and duration expressions, but we consider only linear constraints in all our tools. Time constraints can occur.
-- In the form of guards in state machines and observers.
-- Conditions in LSC.
-- OCL constraints.
-- Explicit time constraints or constraint patterns associated with different UML construct, as they are foreseen in SPT (WCET associated with methods, minDelay, maxDelay associated with channels, "..."); notice that such derived constraints are presently not implemented in the tools, they have to expressed using the basic means for expression of time constraints.
- We have introduced observers mainly as a means for expressing complex time constraints using a UML operational syntax, accessible to the user. They are defined as stereotyped of state machines, where transitions are triggered by semantic level event occurrences (they can be identified using explicitly defined event instances or by using an event matching clause as in the definition of a corresponding event class). An observer allows expressing constraints on the order and/or timing of occurrence of semantic level events and is a means to define dynamic properties depending on time or not. Observers have proven to be well accepted by users. They express safety properties in the form of acceptors (an execution leading to an error state represents an error trace). In addition, observers can express assumptions (a sequence leading to an invalid state is "not to be considered").
- Finally, some minimal concepts have been introduced to define scheduling constraints and general scheduling policies.