Towards a Formalization of Real Time Design Patterns:
From UML-MARTE Profile To Maude Specification
∗ †
Kamel Boukhelfa
LIRE Laboratory
University of Constantine 2
Constantine 25000, Algeria
kamel.boukhelfa@univ-constantine2.dz
ABSTRACT
Design patterns (DPs) and real-time design patterns (RT-
DPs) are described in informal way (UML and natural lan-
guage) to facilitate their understanding by software devel-
opers. However, these descriptions lead to ambiguities and
limiting their correct usage. Moreover, this conventional
representation has reached its limits and in particular for
the representation of temporal proprieties and constraints.
The representation of RTDPs in UML-MARTE profile per-
mits to well express their temporal proprieties and con-
straints and thus, their algebraic specification become more
natural and more efficient.
In this paper, we propose a formalization approach of real-
time design patterns (RTDPs). We present an architecture
support for the formalization process and we show how to
formalize the different concepts of a given RTDP represented
in UML-MARTE profile. Then, we illustrate our approach
by a realistic case study that represents a real-time design
resulting from the use of RTDPs by the means of the instan-
tiation and composition mechanisms. This design is speci-
fied as a set of some generated Maude (based on rewriting
logic) Oriented Object modules. The execution of the latter
allows to verify the feasibility of the proposed formalization
approach.
Keywords
Real-time Design Pattern, MARTE profile, Rewriting Logic,
Maude
∗Mr. Kamel Boukhelfa: Lecturer (preparing a Phd thesis)
in the department of Software Technologies and Informa-
tion Systems - Faculty of New Information Technologies and
Communication - University of Constantine 2, Algeria.
†Pr. Belala: Professor in the department of Software Tech-
nologies and Information Systems - Faculty of New Informa-
tion Technologies and Communication - University of Con-
stantine 2, Algeria.
Faiza Belala
LIRE Laboratory
University of Constantine 2
Constantine 25000, Algeria
faiza.belala@univ-constantine2.dz
1. INTRODUCTION
A design pattern expresses solution of a known and recur-
rent problem in a particular context [7]. Design patterns
are applied in object programming software to improve the
quality of the resulting system.
The reuse concept is also important in the development of
real-time and embedded systems. Thus, design patterns can
be used to capture the experience and allow the reuse of the
”good” solutions to resolve the problems encountered during
the design process of such systems [5, 15].
In the literature, several design patterns qualified as being
”real-time” are proposed in different domains [5]. Intuitively,
the term ”real-time” refers to design patterns those dealing
with the temporal aspects of systems, whereas this is not
always the case. Indeed, real-time design patterns (RTDPs)
deal with the general problems encountered in the design of
real-time systems (that may be or not related to the time)
such as synchronization or memory allocation. The RTDPs
vary according to their areas of application and according
to the design approaches. Generally, design patterns and
also RTDPs were described, until now, by using a com-
bination of textual descriptions, object oriented graphical
notations such as UML diagrams and sample fragments of
code[7, 5, 15]. This informal description of design patterns is
adopted to facilitate their understanding by software devel-
opers. However, informal descriptions give rise to ambigu-
ity, and limit tool support and correct usage. Tool support
can aid pattern mining, detection of pattern within a de-
sign model, and code generation from pattern specification.
Hence, there is a need for a formal specification of the design
patterns to ensure their successful application.
Formal specifications provide a precise and rigorous descrip-
tion for better understanding patterns and their instantia-
tion and composition. The formal specifications of the de-
sign patterns are not intended to replace informal ones, but
to complement them. The object-based design process can
be more productive by adopting a design patterns based
modelling and some steps of analysis and verification to
make sure that the application result is in accordance with
the input design.
In this work, we are interested in the formal specification of
the RTDPs based designs. Thus, we propose a formaliza-
tion approach that define for all used UML-MARTE nota-
tions the equivalent specification in Maude language [3, 11].
Initially, we have presented the global architecture to sup-
port the formalization and in second step, we have applied
the proposed approach for specifying a RT patterns-based
design for verifying its feasibility.
Maude is a high-level language and a high-performance sys-
tem supporting executable specification and declarative pro-
gramming in rewriting logic [2, 4] that we have used as a
formal foundation for the specification of the Pattern-Based
designs. This logic permits to specify both parts of the de-
sign models, namely the structural and dynamic part in a
same formalism.
The rest of this paper is organized as follows. We cite some
relevant work on design patterns, especially those that deal
with representation (formal or not) of design patterns. Af-
ter recalling the used basic concepts of RTDPs, MARTE
profile and rewriting logic via its practical language Maude
in Section 2, we describe in Section 3 the formalization ap-
proach and we show how it is possible to give a formal base
to real-time systems designs thanks to a judicious coupling
of UML-MARTE profile and rewriting theories. The Section
4 is dedicated to a case study, where we apply the proposed
approach to a realistic example. Finally, we conclude the
paper with constructive remarks and future work.
2. RELATED WORK
Among the most existing research work around design pat-
terns dealing with issues related to their representation and
specification, we distinguish two points of view adopted for
this purpose. The first one concerns all works that adopt the
meta-modeling approaches and consequently the definition
of patterns modeling languages based on UML. These works
aim in general to provide solutions for integrate design pat-
terns in CASE tools. The second kind of research work is
characterized by the use of the formal methods to specify
the design patterns and then provide suitable models to the
analysis and verification stages. Thus, we can cite DPML
(Design Pattern Modeling Language)[10], which defines a
meta-model and a notation for specifying design pattern so-
lutions and solution instances within object models.
The meta-model defines a logical structure of DPML objects
which can be used in design patterns and design patterns in-
stances modelling, while the language notation describes the
diagrammatic notations used to represent visually the mod-
els. DPML allows only the specification of the structural
aspect of design patterns and no indications are mentioned
about the composition and the verification of design pat-
terns.
In the same context, Dae-Kyoo Kim et al. [9] present an
UML-based pattern specification language called the role-
based meta-modeling language (RBML), which defines the
solution domain of a design pattern in terms of roles at the
meta-model level. The goal of the RBML is to support
the development of precise pattern specifications that can
be used for the development of pattern tools. The authors
propose a meta-model for the design pattern solution that
will be specialized according to the type of pattern (Static
pattern, interaction pattern, state-machine pattern). Then,
RBML specifies the pattern solutions as a specialization of
the UML meta-model. Being completely based on UML and
its mechanism of instantiation and specialization made that
RBML inherits the lacks of UML owed in its semi-formal
notation.
In the context of the purely formal specification, several at-
tempts to formalize design patterns have been proposed. We
present two significant works namely, the BPSL (Balanced
Pattern Specification Language) [16] and LePUS (LanguagE
for Patterns Uniform Specification) [8], that aim to formal-
ize the structural and behavior aspects of design patterns.
BPSL uses a subset of first-order logic (FOL) to formalize
structural aspect of patterns, while the behavioral aspect is
formalized in TLA (Temporal Logic of Actions). The first-
order logic is justified by its simplicity to express relations
between pattern participants as predicates.
LePUS is a fragment of the monadic high-level order logic
using a limited vocabulary of entities and relations. A Le-
PUS instruction is formed by a list of participants (classes,
functions or hierarchies) and a list of relations between these
participants. A program is represented by a model M which
is a pair < P, R > where P is the universe of the basic
entities (classes and functions) and R = R1, ..., Rn is the
set of the relations between these entities. These relations
are deduced by generalization of all the existing basic re-
lations between participating entities in the GOF patterns
[7]. Hence, a design pattern is described by HOL formulae
which are accompanied by a graphic representation in order
to facilitate its understanding.
In a previous work [6], we have proposed a rewriting logic
based meta-model approach to formalize design pattern so-
lutions and their instantiations. Our proposed meta-model
includes all the common elements of design patterns, so any
design pattern can be expressed in terms of this meta-model.
It provides a high level of abstraction that will cover all the
features of design patterns and it allows a generic represen-
tation that can be used to produce automatically any design
pattern specification.
In the same thought, we give in this paper an alternative
approach to deal with the formalization of the RTDPs.
The main originality of this contribution is the passage from
an UML-MARTE representation of the RTDPs and the RT-
DPs based designs to a Maude specification with consid-
eration of the temporal proprieties and constraints of the
RTDPs defined in [5]. This purpose is achieved by the asso-
ciation of rewriting logic semantics in terms of Maude Object
Oriented Modules to the mentioned models.
3. KEY CONCEPTS
3.1 Real-Time Design Patterns
In object oriented programming (OOP), design patterns are
considered as a mean to encapsulate the knowledge of expe-
rienced software designers and represented it in an under-
standable form in order to permit its reuse.
A design pattern expresses a solution of a known and re-
current problem in a particular context (real-time or not).
They are considered as reusable components that can be ap-
plied in the design phase in order to reduce the complexity
of the software design. For each design pattern, are defined
the roles of classes, relationships between classes and ob-
jects, and how this pattern can be applied to resolve a given
problem in a specific context. The structure describing a
design pattern mainly includes the name, problem, solution
and consequence. Generally, for each design pattern, the
structural part is represented with an UML class diagram,
while the dynamic one is often represented by a collabora-
tion/sequence diagram.
RT design patterns are a kind of patterns that have evolved
specifically for real-time systems, and they provide various
concepts to address the fundamental real-time scheduling,
communications, and synchronization problems [5, 15]. As
a GOF design patterns, RTDPs are represented also in UML
and the most temporal constraints (especially in the inter-
actions) are expressed in the natural language.
3.2 The UML profile for MARTE
The UML profile for MARTE (in short MARTE for Mod-
eling and Analysis of Real-Time and Embedded systems) is
an OMG standard which provides support for specification,
design, and verification/validation stages. This new profile
is intended to replace the existing UML Profile for Schedu-
lability, Performance and Time [13, 14].
Model-based design of RTE systems with MARTE proceeds
mostly in a declarative way. The user can annotate its mod-
els with real-time or embedded concerns using the extensions
defined within the HLAM (High-Level Application Model-
ing) sub-profile.
The HLAM package is depending of both GRM (Generic
Resource Modeling) and CoreElements packages. The con-
cern of the HLAM package is to provide high-level modeling
concepts to deal with real-time and embedded features mod-
eling. Thus, it provides possibilities of modeling on one hand
quantitative features such as deadline and period and, in the
other hand, qualitative features that are related to behav-
ior, communication and concurrency. MARTE provide the
NFP package for Non-functional Properties Modeling. This
sub package of the MARTE specification provides a general
framework for annotating UML models with NFPs. It is es-
pecially focused on formalizing a set of modeling constructs
in order to specify this kind of property in a detailed way
[13].
When modelling the flow of information, UML distinct be-
tween ”active objects” that can initiate this flow and ”pas-
sive objects” that cannot. Active objects exist in their own
thread and have their own address space. At run-time, ac-
tive objects can start or control these information flows. Ac-
tive objects are sequential and they have a task to achieve,
change variables, change the behavior of the program and
so on.
Contrary to the active objects, passive objects do not have
the ability to change or start the flow of execution because
they have to wait another object to call them. Instead, the
passive objects are generally used to store information, and
in many cases, this information can be shared among several
other objects. This can allow passive objects to be viewed
simultaneously, not sequentially. To ensure that the data
contained within have high integrity, UML allows passive
objects to insist that they are accessible sequentially. If two
threads attempt to call the same passive object simultane-
ously, this object may delay the second thread until the first
has finished. However, this approach to express the con-
currency failed to capture real-time proprieties required to
perform pertinent analysis. Hence, MARTE provides Real-
time unit concept (RtUnit) defined in HLAM package. An
RtUnit may be seen as an autonomous execution resource,
able to handle different messages at the same time. It can
manage concurrency and real-time constraints attached to
incoming messages [13].
RtUnit encapsulates in a single entity both the object and
the process paradigms. Any real-time unit can invoke ser-
vices of other real-time units, send signals or data without
worrying about concurrency issues. An RtUnit owns a con-
currency and behavior controller for managing message con-
straints according to its current state and the concurrent ex-
ecution constraints attached to the messages. It also owns
a single message queue for saving the messages it receives
once its execution has started. This message queue is equiv-
alent to the event pool of a UML active object, except that
the semantic variation point is resolved via the possibility
of specifying a scheduling policy for the queue. Messages
contained in the queue can represent operation calls, signal
occurrences or data receptions. Each message can be used to
trigger the execution of a behavior owned by the unit (i.e.,
as described by its main service).
Another important point to consider when modelling con-
currency system is to be able to represent shared informa-
tion. For that purpose, MARTE have introduced the con-
cept of protected passive unit (PpUnit) that units specify
its concurrency policy either globally for all of its provided
services (concPolicy attribute), or locally through the con-
cPolicy attribute of an RtService.
RtUnit and Ppunit may provide real-time services. In the
case of the protected passive units, as they use the schedu-
lable resource of invoking real-time units, it has to be spec-
ified the concurrency policy of the service (concPolicy at-
tribute). The execution of a real-time service may be de-
clared as atomic and it is also possible to specify how the
execution is handled by the unit through the exeKind at-
tribute.
3.3 Rewriting logic and Maude
Rewriting logic is known as being logic of concurrent change
taking into account the state and the concurrent systems
calculus. It is shown as a unifying semantic framework of
several concurrent systems and models [12]. In rewriting
logic, a dynamic system is represented by a rewriting theory
R = (Σ, E, R, L), describing the complex structure of its
states and the various possible transitions between them.
The theoretical concepts of the rewriting logic are imple-
mented through the Maude language [12, 3, 11]. Maude
integrates object oriented programming which are used in
our formalization to encode the DPs and their meta-models
specifications and its logical basis gives a clear definition of
the object oriented semantics and makes it a good choice for
the formal specification of object oriented systems.
The module is the key concept of Maude, it defines a col-
lection of operations and how they interact (algebra). In
Maude, a module will provide a collection of sorts and a
collection of operations on these sorts, as well as the infor-
mation necessary to reduce and rewrite expressions that the
user inputs into the Maude environment. There are three
types of modules in Maude: the functional module (fmod )
that allow defining data types and their functions through
equations theory, the system module (mod ) for defining the
dynamic behavior of a system, and the object-oriented mod-
ule (omod ) that can be reduced to system modules [3, 11].
The following code illustrates a Maude object-oriented mod-
ule BANK-ACCOUNT [3] that specify a bank account and the
operations credit and debit able to affect its content and
the rewriting rules those manage and control the two oper-
ations. The execution of the unconditional rule [credit]
generates the consumption of the message credit(A,M) and
the content of the account is increased. While the execution
of the conditional rule [debit] requires that the condition
(N>=M) is true. The execution of such rule generates the
consumption of the message debit(A,M) and the reduction
of the content of the account:
(omod BANK-ACCOUNT is
protecting INT .
including CONFIGURATION .
op Account : -> Cid.
op bal :_ : Int -> Attribute .
ops credit debit : Oid Nat -> Msg .
var A : Oid . vars M N :Int
rl [credit]: < A : Account | bal : N >
credit(A, M) => < A : Account | bal:N + M >
crl [debit] : < A : Account | bal : N >
debit(A, M) =>
< A : Account | bal : N - M > If N >= M .
endom .)
4. FORMALIZATION APPROACH
4.1 Our contribution
We present in Figure 1, the proposed global architecture
supporting our approach of RTDPs formalization based on
rewriting logic. The left side of the architecture presents
the needed concepts for generating a RTDPs based design.
Thus, we use one or more of the cataloged RTDPs repre-
sented in UML, then we enriched them by the MARTE no-
tations. The resulting models are instantiated and composed
for providing a design for a given system.
In the other side, the generation approach of the Maude
specifications, associated to RDTPs and their underlined de-
signs in all their forms (UML, MARTE), is depicted. Here,
we need to define as Maude modules all RTDPs and the in-
stantiation and composition mechanisms. So, from the RT-
DPs Maude module and the instantiation mechanism defi-
nition, some modules defining the instances are generated.
The composition module uses these instances to generate
the Maude specification of the RT design. We will note here
that the formalization process is performed in parallel with
the design process.
The definition of the RTDPs meta-model (in UML and Maude)
serves to automate the generation of the specifications at the
different levels. For the sake of the paper space, we will limit
our work in this paper to study the passage from the result-
ing RT design represented in MARTE to the Maude specifi-
cations. Besides, we will verify the feasibility of the formal-
ization approach by applying it on a realistic case study.
For this purpose, we use firstly a given design pattern to
generate an UML design (structural and dynamic parts).
The result design will be enriched by the MARTE notations,
namely the concepts defined in HLAM sub-profile such as
RtUnit, PpUnit and Rtfeature, and those defined in the
NFP sub-profile such as NFP_DateTime, NFP_Duration and
Figure 1: The global architecture support of RDTPs
formalization.
NFP_Frequency.
The second step consists to pass from UML-MARTE to
Maude specifications. Here, we use Full-Maude, an exten-
sion of Maude that, allows us to manipulate the object-
oriented concepts such as objects, classes, attributes, etc.
4.2 Formalization of the structural part
We can note the existence of a correspondence between a
some concepts of Maude language and UML-MARTE con-
cepts. Unfortunately, this correspondence is not fully es-
tablished, there are various concepts in UML-MARTE with
no direct equivalent in Maude such as, associations, method
calls in sequence diagram and the temporal properties and
constraints.
The structural part of a design pattern is represented as an
UML class diagram with the different classes and relation-
ships between them. This part will serve as a model to gener-
ate, by means of the instantiation mechanism any structural
design based on this pattern. A class is a set of attributes
and methods, and it can be related to an another class
through inheritance mechanism to emphasize parental rela-
tionships. Other relationships are possible between classes,
each relationship is represented by a specific arc in the class
diagram.
The table 1 contains the MARTE concepts and their corre-
spondences in Maude. For some MARTE concepts without
direct correspondence, we have also proposed their defini-
tions in Maude. Particular attention is given to the MARTE
concepts, such as stereotyping and the definition of methods.
Thus, we propose the following: For the stereotyping, we de-
fine a new class for each stereotype and so, the stereotyped
class (in MARTE) is represented by a subclass in Maude.
While, for the specification of the methods definition within
classes, we define a new sort called method and we add the
declaration of a Maude operation that permits to link each
method to its appropriate class (op Methods : class ->
SetMethod). In addition, we use the predefined concepts
in several modules of Maude such as the SET module, for
defining empty and non-empty set (Set, NeSet), and others
modules such as BOOL, FLOAT, NAT and STRING to express re-
spectively the types Boolean, Float, Natural and string of
characters. The figure 2 shows how to use the above cor-
 • the trigger object,
Table 1: Correspondence between MARTE and
Maude concepts • the target object,
MARTE Concept Maude Concept
• the Occurrence Kind (occkind),
Class/objet Class/Oid
Attribute Attribute • the triggering time (Tref: reference time) and
Directed Association Operation
• the deadline (reldl) (time to response).
Non-Directed Association Two operation
(one for each direction)
Association 1..1 operation op For the occurrence kind of a signal (occkind), we define a
Association 1..* op − > Set Maude operation called periodic that permits to identify
Association 1..n op − > NeSet the nature of this signal appearance (periodically or not).
(not empty Set) In the case of a periodic signal the periodVal operation is
Composition Operation defined to get the value of the period (for the simplicity, we
inheritance Subclass consider the default unit of time (ms)). The others elements
stereotyping Defining a new class that characterize a signal are represented in Maude language
and subclass as operations upon this signal. The following fragment of
Method sort method + op Methods Maude code illustrates the specification of the signal ins
with a t0 as triggering time:

Sorts signal Value .

Var ins : signal .
Var t0 : Value .
op Time_ref : signal -> Value .
eq tref(ins) = t0 .

Object creation: creating objects that compose the system

is achieved in a natural way in Maude through a rewriting
rule that creates a new objet form a configuration.

rl [ins] <O1 : C1 | > Insert(O2, C2)

=> < O1 : C1 | > <O2 : C2 | > .

We need also to define a new operation Instance : op

Figure 2: An example of an UML design model and
its specification in the Maude language, based on
the MARTE-Maude correspondences.
respondence table for passing from the UML representation
to a Maude specifications.
4.3 Formalization of the dynamic part
The dynamic part of a design pattern represents the interac-
tion between different objects instantiated from classes that
form a pattern-based design. This part is often represented
by a sequence diagram with all the interactions between ob-
jects shown as signals.
In MARTE, we can add the rtf stereotype at the methods
dealing with real-time features. So, the <<rtf>> insert()
method for example, means that the insert() method has
temporal properties such as (deadline, reference time, etc.).
The temporal constraints are expressed in OCL (Object
Constrained Language) such as a maximum time to per-
form an activity. In the following, we present the proposed
process to specify in Maude the dynamic aspects. Method
call: We declare a new sort called Signal that expresses the
interaction between two objects. A signal is characterized
by:
Instance : class -> Oid . This operation represents
the objet creation signal. Thus, we can specify all concerned
objects in the execution of a given activity (represented as
sequence diagram). These objects can be declared at the
start of this activity or created during the execution. Tem-
poral constraints: they represent the conditions on the
actions that need to be satisfied, such as the necessary time
to perform a given activity. In MARTE, these constraints
are expressed in the OCL language (Object Constraints Lan-
guage). In Maude, we define two sorts, Time and Value to
specify the temporal variables (eg. triggering instants of
signals) and their values. In consequence, it is necessary to
have an operation to get the value of an instant t (Rvalue)
and a conditional equation to check whether the imposed
constraints is verified or not (Satisfy).
5. CASE STUDY: MODELLING AND
SPECIFYING A "CRUISE CONTROL
SYSTEM"
This system control and regulate the speed of a car accord-
ing to the situations encountered (obstacle, car ahead too
closely, etc.). To achieve these purposes, the controller re-
quires the services of three types of sensors, a Speed Sensor
and a Laser device to calculate the distance between the
car and obstacles and a radar to detect possible obstacles.
We will consider in this study for simplicity, only the Speed
Sensor from the car and the Laser device.
Figure 3: The structure of the Real-Time Design
pattern ”Observer” represented as an UML class di-
agram.
5.1 System Modelling in MARTE profile
For modelling the system, we have used the instantiation
and composition process of patterns. Thus, we have used
Observer and Sensor patterns and we have composed their
instances to generate the structural design of the system.
The composition is achieved in a simple way, namely through
the overlapping of common elements in the two instances.
In our design, we use the RtUnit concepts for stereotyping
the classes which encapsulate operations on information de-
tained in classes stereotyped by PpUnit. These latter permit
to protect information through the concPolicy attribute,
and so if the value of this attribute is garded only one ob-
ject can modify the information. The others objects are
delayed.
Real-Time Design pattern ”Observer”: The problem
addressed by the Observer Pattern (Figure 3) is how to
notify some number of clients in a timely fashion according
to some abstract policy, such as ”when it changes,” ”every so
often,” ”at most every so often,” and ”at least every so often”
[5].
A first approach is to notify every client to query the data
value but, this can be computationally wasteful, especially
when a client wants to be notified only when the data value
changes. Another solution is to design the server so that
it has initially knowledge about its clients (contradictory to
the client/server philosophy). The basic solution offered by
the Observer Pattern is to have the clients ”subscribe” to the
server to be notified about the value in question according
the defined policy.
Real-time Design Pattern ”Sensor”: A sensor is de-
fined as a device that measures or detects a physical phe-
nomenon (temperature, pressure, speed, etc.) and trans-
mits the values at real-time to the command ends. In the
structure of the Sensor RT pattern (Figure 4) [1], the ab-
stract class sensor can be specialized in four subclasses rep-
resenting the four possible types of sensors (Active Sensor,
Figure 4: The structure of the Real-Time Design
pattern ”Sensor” represented as an UML class dia-
gram.
Passive Sensor, Fixed Sensor and Mobile Sensor).
We use Active Sensor pattern that is able to send signals
Setvalue to one or more objects for modifying the measured
value. The class measure is a required class in the RT pat-
tern Sensor, it stores the data taken by the sensor, while the
attributes (timestamp, validity duration) are used to rep-
resent the characteristics of real-time data supported. The
class Observed element is used for the physical device de-
scription, which is supervised by one or more sensors, it can
be a wheel, a car or a natural phenomenon.
5.1.1 Modelling of the structural design
Firstly, we use two instances of the pattern Observer to
model the structure of the sub-systems (Speed Controller
and Distance Controller). For each sub-system we need to
instantiate Observer and Sensor patterns and so, compose
this instances. We use the MARTE notation to represent
the different models.
Instantiation of Observer pattern: we use an instance of
Observer pattern (Figure 5) to model the Speed Controller
sub-system. The resulting model is represented in MARTE
and enriched with temporal and NFP proprieties. In the
same way we proceed for modelling Distance Controller sub-
system. The table 2 presents the result of instantiation of
Observer RT pattern to model the two sub-systems and the
role of the different elements in the structural design.
Instantiation of Sensor pattern: In second time, we use
two instances of the Sensor RT pattern (Figure 6) to model
the capturing of the speed rotation of a car wheel and the
detection of the possible obstacles in front of a car and mea-
sure the distance that separate them from the car (Laser
device).
The table 3 presents the result of instantiation of Sensor
RT pattern and the role of the different elements in the
structural design.
The composition of the instances of Observer and Sensor
Table 2: Instantiation of ”Observer” Design Pattern Table 3: instantiation of ”Sensor” Design Pattern
related to the two sub-systems. related to the two sensors.
Observer pattern Speed Distance Sensor pattern Speed Sensor Distance Sensor
Controller SS Controller SS Active Sensor Rotation Sensor Laser
Concrete client Cruise Cruise Measure Speed Distance
Controller Controller Observed Element Wheel Obstacle
Abstract client Speed Distance
client Client
Concrete Subject Speed Distance model the temporal behavior of these interactions (occur-
Controller Controller rence mode, deadline, etc.). MARTE profile also allows us
Notification Handle Speed Distance to set time restrictions upon interactions with ”time con-
Notify Notify straint” (eg. t2-t1 < (5 ms)).
Data Speed Distance
The design is based on the Observer and Sensor patterns.
Each object which requests a service (Concrete client)
must subscribe in the list of the notified-objects of the corre-
sponding service controller object (Concrete Subject). The
service controller will insert the objects (clients) in its sched-
ule list and then, it notifies them periodically by sending the
value of measuring of a given propriety (speed and distance
in this case).

Figure 8 shows the sequence diagram for the Cruise Control

System to perform the task of capturing the car speed and
the distance in the case of a nearly car. The cruise control
object needs two services (internal speed and distance), so
it must subscribe into both lists of notification.

At the time t1[i] (each action i starts at t1[i] to get a speed

Figure 5: An instance of the Real-Time Design pat-
tern ”Observer” represented in MARTE profile.
value), a message is sent by the speed controller object. This
message represents a call to getvalue method. The message
is stereotyped by RtFeature to represent temporal proper-
ties such as the period of the occurrence of this message (20
ms). It will be followed by other interactions for notifying
the clients. These interactions must be completed at time
t2 with a maximum delay of 5 ms.

At the time t3[i] (an action i starts at t3[i] to get a distance

value), the distance controller object will call the getvalue
method of distance object that is stereotyped by RtFeature
too. It will be followed by other interactions for notifying
the clients. These interactions must end at time t4 with a
maximum delay of 5 ms.

The occurrence of each message (getvalue) is every 20 ms,

Figure 6: An instance of the Real-Time Design pat-
tern ”Sensor” represented in MARTE profile.
and the sequence of actions for the notification takes is less
than 5 ms. Thus, an aperiodic signal can be processed in
the rest of the period (i.e. in 15 ms), and each aperiodic
signal arrived between t1 and t2 or between t3 and t4 will
be delayed.

patterns respectively regarding the common elements (the

Speed class in first case, and Distance class in the second 5.2 Maude specifications of the
one) produces the design model of the complete system (Fig- designed system
ure 7). The major advantage of the rewriting logic and its language
Maude is the ability to specify in the same formalism both,
5.1.2 Dynamic design Modelling the structural and the dynamic aspects of a given the system.
Here we describe the dynamic aspect of the system by using
a sequence diagram. This diagram shows a scenario of data
acquisition and how the system will react to synchronous or 5.2.1 Structural Design specification
asynchronous events. The interactions that have temporal We start the specification of this part by declaring the sev-
properties are stereotyped as RtFeature. This allows us to eral sorts:
Figure 7: Representation of the structural part of the ”Cruise control system” in MARTE profile, resulting
from the composition of an instance of ”Observer” with an instance of ”Sensor”.

Figure 8: Representation of the dynamic part of the ”Cruise control system” as a sequence diagram that
models the capturing activity of a speed and distance.
--- sorts one in each direction) is done in the following Maude code.
Sort Method . Each association is specified as a Maude operation taking as
Sort NFP_duration . parameter the first class and result the second one.

The multiplicity is also specified by Set and NeSetfor denot-

The second step is to define all classes within the design as
ing respectively (1..*) and (0..*) multiplicities.
Real-time units or passive protected units regarding for each
class its role in the design. Stereotyping, inheritance are also
defined. --- Associations definition
--- as Maude operation
--- Classes definition
class Speed . op Speed_Sensor : Speed ->
class Rotation_Sensor | Rotation_Sensor .
sensor_description : op Speed_Measure :
String , periodicity : Rotation_Sensor -> Speed .
NFP_duration . op Speed_C :
class Wheel | statue : String , Speed_Controller -> Speed .
description : String . op Notified :
class Speed_Controller . Speed_Controller ->
class Speed_Notify . Set{Speed_Notify} .
class Speed_Client . op Use_Speed :
class Cruise_Controller . Speed_Controller ->
class Distance_Client . NeSet{Speed_Client} .
class Distance .
class Distance_Controller . --- ...
class Distance_Notify .
class Laser | eq Methods(Speed) = getValue .
sensor_description : String , eq Methods(Speed_Controller) =
periodicity : NFP_duration . Subscribe Unsubscibe .
class Obstacle | statue : String , eq Methods(NotifieV) = getnext .
description : String .
5.2.2 Dynamic Design specification
As we have mentioned, a dynamic design is represented as
RtUnit and PpUnit stereotypes are considered as inheritance a sequence diagram and it shows the execution scenario of
in Maude : an activity. This diagram models the capturing activity (in
this case speed and distance).
class RtUnit | isDymamic : Bool ,
ismain : Bool , The specification of this model is divided in two parts. In
poolsize : Float , the first one, we define all sorts, operations and equations
main : String . requested for each activity. However, the second is specific
Subclass Rotation_Sensor Speed_Controller for each activity (capturing activity).
Distance_Controller Laser < RtUnit .
class PpUnit | concpolicy : String . The important element in this model is the signal. Thus, we
subclass Speed Distance < PpUnit . define a sort Signal and all temporal features were defined
as Maude operations upon it.
The different methods in classes are specified as a Maude Part 1 : General Specification
operations. Furthermore, we have defined a Methods oper-
ation for permitting for each method to know the class to
which it belongs. --- classes instantiation definition
op Instance : class -> Oid .
--- temporal Features of signal
--- ...
sort Signal .
sort Time .
op Methods : -> Set{Method} .
op getValue : -> Method .
vars
op Speed_Subscribe : -> Method .
O : Oid C : class .
op Speed_Unsubscribe : -> Method .
op Distance_Subscribe : -> Method .
op operation : Signal -> Method .
op Distance_Unsubscribe : -> Method .
op Trigger : Signal -> Oid .
op getnext : -> Method .
op Target : Signal -> Oid .

The specification of the different associations between classes --- add ceq to ensure that invoked method
(undirected association is considered as a two associations, --- belongs to the class of this object

ceq Target(S : Signal) = < O : C | >
if operation(S) in Methods(C) .
op periodic : Signal -> Bool .
op periodVal : Signal -> Float .
--- if the signal occurrence is
--- periodic then, the period
--- value must be identified.
var t1 : Time .
op GETVALUE_S : -> Signal .
eq operation (GETVALUE_S) = getValue .
eq Trigger (GETVALUE_S) = Speed_C .
eq Target (GETVALUE_S) = Sp .
eq Time_ref (GETVALUE_S) = t1 .
eq periodic (GETVALUE_S) = TRUE .
eq periodVal(GETVALUE_S) = 20 .
eq relDl (GETVALUE_S) = 3.3 .

ceq periodVal(S : Signal) = Specification of temporal constraints as rewriting Rules.

v : Float if periodic(S).
op Time_ref : Signal -> Value .
op relDl : Signal -> Float . msg Speed_Subscrib_Call :
op Rvalue : Time -> Float . Oid Oid -> Msg [ctor] .

msg Distance_Subscrib_Call :
Part 2 : Specification related to a capturing (Speed and Oid Oid -> Msg [ctor] .
Distance) activity
vars C S Not_C : Oid .

--- Object as variables op Speed_Subscrib_Signal : ->

Signal .
Vars
Cruise_C Speed_C Distance_C Notify_Sp eq operation(Speed_Subscrib_Signal)
Notify_D Sp Dis Rot_Sens Las : Oid . = Speed_Subscibe .

--- System objects creation eq Trigger (Speed_Subscrib_Signal)

= Cruise_C .
eq Instance(Cruise_Controller) =
< Cruise_C | isDymamic : false eq Target (Speed_Subscrib_Signal)
ismain : false poolsize : 10 > . = Speed_C .

eq Instance(Speed_Client) = Speed_Subscrib_Call
< Speed_C | isDymamic : false (Cruise_C , Speed_C) .
ismain : true poolsize : 10
main : Speed_Subscribe > . rl[Speed_Sub]
< C : Cuise_Controller >
eq Instance(Distance_Client) = < S : Speed_Controller >
< Speed_C | isDymamic : false Speed_Subscrib_Call =>
ismain : true poolsize : 10 < C : Cuise_Controller >
main : Distance_Subscribe >. < S : Speed_Controller >
< N : Speed_Notify > .
eq Instance(Speed_Notify) :
Notify_Sp .
Definition of a conditional rewriting rule to ensure that a
eq Instance(Distance_Notify) :
time constraint is verified.
Notify_D .

eq Instance(Speed) = msg satisfy : Signal Signal

< Sp | concpolicy : garded > . Float -> Bool .

eq Instance(Distance) = crl [ satisfy ]

< Dis | concpolicy : garded > . satisfy ( S1 : Signal ,
S2 : Signal , T : Flaot)
eq Instance(Rotation_Sensor) = if Rvalue( (Time_ref(S2)
< Rot_Sens | isDymamic : + reldl(S2))
false poolsize : 10 > . - Time_ref(S1)) < T .

eq Instance(Laser) = Satisfy(GETVALUE_S , GETNET_S , 5) .

< Las | isDymamic : --- ...
false poolsize : 10 > .
For paper space limit, we have presented only a set of frag-
Specification of signal GETVALUE_S. ments of the code of the different Maude Object Oriented
Modules. The complete specification of the example was
tested in Maude environment (Version 2.6). The execution
of some examples have allowed us to verify the feasibility of
our approach. We intend, in this context and in the near
future, to test formally the resulting specifications by the
means of the Maude LTL model checker [3].
6. CONCLUSION
Real-time design patterns are a kind of pattern that has
evolved in order to support the development of real-time
systems and model timing aspects such as concurrency, syn-
chronization and scheduling as well as other aspects of the
development of any other system such as resource allocation
and memory management. The deficiencies encountered for
the representation of GOF patterns are becoming more ac-
centuated in the representation of RTDPs.
In this paper, we have proposed a formalization approach
of real-time patterns-based designs. Thus, we have present
firstly, the global architecture supporting the formalization
process of the RTDPs. In a second step, we have presented
the formalization approach and we have shown how to for-
malize the different concepts of the design in Maude.
We have used the notation provided by UML MARTE pro-
file that enables to enhance the designs resulting from the
instantiation and composition of RTDPs by expressing the
real-time and non-functional properties. Then, rewriting
logic via its Maude language was adopted for the specifi-
cation of the results designs. This permits to pass from
a semi-formal representation to a formal one and consider-
ing both aspects of the design, namely the structural and
dynamic part. Our approach was illustrated by a realistic
example ”A Cruise control System” then, we have identified
its relevance for producing all Maude modules executing the
entire example.
We intend to extend the present work in two ways:
The first is to define a profile or meta-model for real-time
patterns and thus allow this latter to generate all possible
patterns. Then, define a pattern instantiation mechanism
to generate all possible solutions in conformity with their
patterns.
The second is to formalize the meta-model defined and the
instantiation mechanism, and in consequence, ensure for-
mally patron-instance conformity. For this purpose, we plan
to explore the RT-Maude (an extension of Maude for speci-
fying and analyzing the real-time and the hybrid systems) to
code the specification that will be more suitable to perform
analysis and verifications of the system proprieties.
7. REFERENCES
[1] S. R. Boubaker, N. Bouassida, C. Duvallet,
R. Bouaziz, and B. Sadeg. A process to derive
domain-specific patterns: Application to the real time
domain. In B. Catania, M. Ivanovic, and B. Thalheim,
editors, ADBIS, volume 6295 of Lecture Notes in
Computer Science, pages 475–489. Springer, 2010.
[2] M. Clavel, F. Durán, S. Eker, P. Lincoln,
N. Martı́-Oliet, J. Meseguer, and J. F. Quesada.
Maude: specification and programming in rewriting
logic. Theoretical Computer Science, 285(2):187–243,
2002.
[3] M. Clavel, F. Durán, S. Eker, P. Lincoln,
N. Martı́-Oliet, J. Meseguer, and C. L. Talcott,
editors. All About Maude - A High-Performance
Logical Framework, How to Specify, Program and
Verify Systems in Rewriting Logic, volume 4350 of
Lecture Notes in Computer Science. Springer, 2007.
[4] M. Clavel and J. Meseguer. Internal strategies in a
reflective logic. In Proceedings of the CADE-14
Workshop on Strategies in Automated Deduction
(Townsville, Australia, July 1997), pages 1–12, 1997.
[5] B. P. Douglass. Real-time design patterns : robust
scalable architecture for real-time systems. The
Addison-Wesley object technology series.
Addison-Wesley, Boston, San Francisco, Paris, 2003.
[6] H. Douibi, K. Boukhelfa, and F. Belala. A rewriting
logic-based meta-model for design patterns
formalization. In PATTERNS 2011 : The Third
International Conferences on Pervasive Patterns and
Applications, pages 84–89, 2011.
[7] E. Gamma, R. Helm, R. Johnson, and J. Vlissides.
Design Patterns: Elements of Reusable Object-oriented
Software. Addison-Wesley Longman Publishing Co.,
Inc., Boston, MA, USA, 1995.
[8] E. Gasparis. Lepus: A formal language for modeling
design patterns. In Toufik Taibi (ed) Design Pattern
Formalization Techniques, pages 357–372. IGI Global,
2007.
[9] D. kyoo Kim, R. France, S. Ghosh, and E. Song. A
uml-based metamodeling language to specify design
patterns. In Patterns, Proc. Workshop Software Model
Eng. (WiSME) with Unified Modeling Language Conf.,
2003.
[10] D. Mapelsden, J. Hosking, and J. Grundy. Design
pattern modelling and instantiation using dpml. In
CRPIT ’02: Proceedings of the Fortieth International
Conference on Tools Pacific, pages 3–11, Darlinghurst,
Australia, Australia, 2002. Australian Computer
Society, Inc.
[11] Maude.cs.uiuc.edu. The maude system, 2015.
http://maude.cs.uiuc.edu, Last viewed january 2015.
[12] J. Meseguer. Rewriting logic as a semantic framework
for concurrency: a progress report. In U. Montanari
and V. Sassone, editors, CONCUR, volume 1119 of
Lecture Notes in Computer Science, pages 331–372.
Springer, 1996.
[13] Omgmarte.org. The uml profile for marte: Modeling
and analysis of real-time and embedded systems |
www.omgwiki.org/marte, 2015.
http://www.omgmarte.org/, Last viewed january
2015.
[14] Omg.org. Sptp, 2015.
http://www.omg.org/spec/SPTP/, Last viewed
january 2015.
[15] D. C. Schmidt, M. Stal, H. Rohnert, and
F. Buschmann. Pattern-oriented software architecture.
Volume 2. , Patterns for concurrent and networked
objects. Wiley series in software design patterns. J.
Wiley & Sons, 2001, Chichester, New York, Weinheim,
2000. retirages 2004, 2005, 2006, 2007, 2011.
[16] T. Taibi and D. C. L. Ngo. Formal specification of
design patterns - a balanced approach. Journal of
Object Technology, 2(4):127–140, 2003.