Modeling Structural, Temporal and Behavioral Features of a Real-Time

Database

Nada Louati

, Raﬁk Bouaziz

, Claude Duvallet

and Bruno Sadeg

MIRACL-ISIMS, Sfax University, BP 1088, 3018, Sfax, Tunisia

LITIS, UFR des Sciences et Techniques, BP 540, 76 058, Le Havre Cedex, France

Keywords:

Real-time, Database, MARTE, UML-RTDB, Proﬁle.

Abstract:

Real-time databases are different from traditional databases in that they have timing constraints on data and

on transactions upon the data. The design of this kind of databases must consider both temporal aspects of

data and timing constraint of transactions in addition to the logical constraints of the database. This paper

proposes a new UML proﬁle that extends UML with concepts related to real-time databases design. These

extensions aim to accomplish the conceptual modeling of a real-time database according to three aspects:

structural, temporal and behavioral. Our propositions is based on MARTE (Modeling and Analysis of Real-

Time and Embedded systems) proﬁle which provides capabilities of modeling concepts to deal with real-time

and embedded system features. The proposed proﬁle is illustrated by a case study in the context of Ait Trafﬁc

Control System.

1 INTRODUCTION

Real-Time DataBases (RTDBs) are typically used to

manage environmental data in computer control ap-

plications, such as air trafﬁc control, automated man-

ufacturing, and military command and control (Ra-

mamritham, 1993). The design of such RTDBs dif-

fers from both that of real-time systems and that of

conventional database management systems. The de-

signers of RTDBs much consider both temporal as-

pects of data and timing constraints of transactions in

addition to logical constraints of the database

The design of RTDBs is performance-and

semantic-dependent. It must consider factors such as

sensor data, derived data and quality of data manage-

ment, temporal semantics in transactions scheduling

algorithmsand concurrencycontrol protocols, to meet

the timing constraints deﬁned by the real-time appli-

cations (Idoudi et al., 2010). This paper proposes a

new UML proﬁle that incorporates these concepts. It

is based on a subset of concepts inspired from the

HLAM, NFP, and TIME packages of MARTE. The

motivations behind these extensions are three-folds:

(i) to have new notations distinguishing quantitative

and qualitative features of RTDBs, (ii) to facilitate

the modeling of timing aspects of data and transac-

tions, (iii) to accomplish the conceptual modeling of

RTDBs. This proﬁle not only captures the structural

aspects of a RTDB features, but also the temporal and

behavioral aspects.

The remainder of this paper is structured as fol-

lows: in Section 2, we present the related works. In

Section 3, 4, and 5 we respectivelyaddress the model-

ing of structural, temporal, and behavioral aspects of

RTDBs. In Section 6, we present a case study to more

illustrate our proposals. In Section 7 we conclude the

paper and we give some perspectives of our work.

2 RELATED WORK

In recent years, several UML proﬁles have been pro-

posed for modeling real-time systems to depict its

real-time constraints. Only a few of these UML pro-

ﬁles address RTDBs modeling.

In (DiPippo and Ma, 2000), DiPippo and Ma de-

scribe an UML package, called RT-Object, for spec-

ifying RTSORAC object. This UML package con-

tains real-time attributes, real-time methods, compat-

ibility functions and constraints. The RT-Object pack-

age is based on a past standard of UML which is

UML 1.3 Extension Mechanisms package. Further-

more, imprecise computation encapsulated within the

RTSORAC object model is described in the context of

Epsilon Serializability (Ramamritham and Pu, 1995),

119

Louati N., Bouaziz R., Duvallet C. and Sadeg B..

Modeling Structural, Temporal and Behavioral Features of a Real-Time Database.

DOI: 10.5220/0003975601190125

In Proceedings of the 14th International Conference on Enterprise Information Systems (ICEIS-2012), pages 119-125

ISBN: 978-989-8565-10-5

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

Figure 1: HLAM package speciﬁcation in MARTE.

and does not support the notion of quality of data in-

troduced in (Amirijoo et al., 2006).

Another work proposed the UML-RTDB proﬁle

(Idoudi et al., 2008a) (Idoudi et al., 2008b) to ex-

press RTDB features in a structural model. It sup-

plies concepts for RTDBs modeling such as real-time

attributes, real-time methods and real-time classes.

However, the proposed extensions are based on the

Evolutionary Stereotype concept (Debnath et al.,

2003) which is not a standard way of extending UML.

MARTE (OMG, 2009) is an industry standard of

the OMG for model-driven development of embed-

ded systems (OMG, 2009). It aims at providing sup-

port for speciﬁcation, design, validation, and veriﬁ-

cation stages in real-time and embedded system de-

velopment. The richness of MARTE proﬁle in terms

of concepts offers an interesting common modeling

basis to adequately specify many design features of

RTDBs. However, the notions of real-time data and

real-time transactions, which are the basis features of

RTDBs are missing in MARTE.

3 MODELING OF STRUCTURAL

ASPECTS

3.1 High Level Application Modeling in

MARTE

The HLAM package of MARTE proposes concepts

that enable to describe both quantitative and quali-

tative features of real-time applications at a high ab-

straction level. Figure 1 depicts the basic stereotypes

associated with the HLAM package. An RtUnit may

be seen as an autonomous execution resource that

owns one or more schedulable resources to handle in-

coming messages. RtUnits may provide real-time ser-

vices. The RtService stereotype has been introduced

for that purpose. The RtFeature stereotype is used to

annotate model elements with real-time features ac-

cording to set of RtSpeciﬁcation associated with this

stereotype. It can be attached to multiple kinds of

modeling elements (i.e., behavioral features, actions,

messages, signals, and ports). For a full description

of all these stereotypes, the reader may refer to the

speciﬁcation document of MARTE (OMG, 2009).

Figure 2: RTDB Proﬁle Metamodel.

3.2 Modeling of RTDB Structural

Features

We propose new stereotypes expressing RTDB fea-

tures in a structural model on the one hand, and ac-

cording to the MARTE proﬁle on the other hand. Fig-

ure 2 shows the extensions proposed to some meta-

classes belonging to the class diagram. In order to

take advantages of some MARTE concepts, the pro-

posed proﬁle imports stereotypes from HLAM, NFP,

and VSL sub-proﬁles.

3.2.1 Stereotypes for Real-Time Data

Real-time attributes are divided into two types: sensor

attributes and derived attributes (Ramamritham et al.,

2004). Sensor attributes are used to store sensor data

which are issued from sensors. Derived attributes are

used to store derived data which are calculated from

sensor data. Thus, we deﬁne two stereotypes, sensor

and derived, in order to declare respectively sensor

and derived attributes in the class diagram. As illus-

trated in Figure 2, we deﬁne an abstract stereotype,

called realTimeProperty, that factorizes validity du-

ration property which indicates the amount of time

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

120

during which the attribute value is considered valid.

We use the MARTE NFP Duration datatype as a type

for the validity duration feature.

We characterize each sensor stereotype by two

properties : maximum data error and periodicUpdate.

Maximum data error indicates the maximum devia-

tion tolerated between the current attribute value and

the updated value. It is of type NFP Real. Maximum

data error represents a non-functional property spec-

ifying the upper bound of the error. We propose to

associate the Nfp stereotype of MARTE proﬁle to the

maximum data error attribute. PeriodicUpdate refers

to a periodic operation of the class that owns the sen-

sor attribute. The role of this periodic operation is to

update the current value and the timeStamp ﬁelds of

the sensor attribute. It is of type Operation.

As shown in Figure 2, we characterize derived

stereotype by sporadicUpdate property, that refers to

a sporadic operation of the class that owns the derived

attribute. This sporadic operation is used to update the

current value and the timeStamp ﬁelds of the derived

attribute.

Each real-time attribute value is characterized by

a timestamp, which indicates the time at which it was

last updated. So, for each real-time attribute value

corresponds a timestamp, which distinguishes it from

other attribute’s values. Whereas, the values of the

validity duration and maximum data error ﬁelds are

the same for the same real-time attribute.

3.2.2 Stereotypes for Real-Time Transactions

A real-time transactions may be aperiodic, periodic,

or sporadic (Ramamritham et al., 2004). It has timing

constraints such as deadline and period. We deﬁne

three stereotypes, aperiodic, periodic, and sporadic

(cf. Figure 2) in order to declare respectively ape-

riodic, periodic, and sporadic operations in the class

diagram. Each of these stereotypes is characterized

by a deadline, which indicates the last time by which

the method execution must be completed. Thereby,

we deﬁne an abstract stereotype, called realTimeOp-

eration, which is used to annotate model elements

(i.e. Operations) with real-time features according to

set of RtSpeciﬁcation associated with this stereotype.

RtSpeciﬁcation possesses nine tagged values among

which: relDl, occKind, and priority. The relDl at-

tribute speciﬁes the deadline of a method execution.

The occKind attribute indicates the arrival transaction

speciﬁcation (i.e. periodic, aperiodic, or sporadic).

For a periodic (respectively aperiodic and sporadic)

transaction, the PeriodicPattern (respectively Aperi-

odicPattern and SporadicPattern) enumeration literal

is selected for ArrivalPattern attribute of the occKind

property. The priority attribute speciﬁes the priority

Figure 3: Time Speciﬁcation in MARTE.

order of a transaction. The realTimeOperation stereo-

type factorizes also two properties: concPolicy and

isAtomic. When the value of isAtomic is true, the

method execution is done as one individual unit. This

fact coincides with the atomicity property of a trans-

action. However, in RTDBs, this feature is relaxed in

order to allow the validation of a transaction even if

only a part of its actions have been executed (Agrawal

et al., 1994). So, in our work, we consider that the

value of the isAtomic property is always false. The

concPolicy property speciﬁes the concurrency policy

of a transaction. The values of this property may be:

reader, writer or parallel. A writer transaction im-

plies that multiple calls from concurrent transactions

may occur simultaneously and will be treated as soon

as concurrency on data allows its execution. A reader

transaction implies that multiple calls from concur-

rent transactions may occur simultaneously and will

be executed simultaneously if there is no writer trans-

action using one or more data that the reader trans-

action needs. A parallel transaction is a transaction

whose actions do not use any data of the database in

reading mode nor in writing mode. In our work, we

consider that for an update transaction, which can pe-

riodic or sporadic, the concPolicy property is writer.

3.2.3 Real-Time Class Stereotype

The design of a RTDB, which is by deﬁnition a

database system, has to take into account the manage-

ment of many components such as queries, schemas,

transactions, commit protocols, concurrency control

protocol, and storage management (Stankovic et al.,

1999). In order to deal with time-constrained data,

time-constrained operations, parallelism, and concur-

rency property inherent to RTDBs, we introduced the

RealTimeClass stereotype. This stereotype speciﬁes

that instances of a class will encapsulate real-time

data and real-time operations and a local concurrency

mechanism. Because of the dynamicnature of the real

world, more than one transaction may send requests

to the same object. Concurrent execution of these

transactions allows several methods to run concur-

rently within the same object. To handle this essential

property of RTDB systems, we associate to each ob-

ject a local concurrency control mechanism, named

local controller, that manages the concurrent execu-

ModelingStructural,TemporalandBehavioralFeaturesofaReal-TimeDatabase

121

tion of its methods. Thus, the object receives mes-

sages in its mailbox awaking its local controller that

checks the timing constraint attached to messages and

selects one message following a special scheduling al-

gorithm. The local controller veriﬁes the concurrency

constraints with the already running methods of the

object. Then, it allocates a new thread to handle the

message when possible. When a method terminates

its execution, the corresponding thread is released and

concurrency constraints are relaxed. In our work, the

scheduling algorithm adopted by the mailbox is EDF

(EarliestDeadlineFirst). For that purpose, we import

from MARTE library the SchedPolicyKind enumera-

tion which deﬁnes the most common kind of schedul-

ing policy. Add to that, the concurrency control pro-

tocol adopted by the local controller is 2PL-HP (Two

Phase Locking-High Priority). In 2PL-HP, all data

conﬂicts are immediately resolved by aborting lower

priority transactions. Thereby, we enhance our proﬁle

model library by a new enumeration type, called Con-

currencyControlKind, in order to deﬁne concurrency

control policies (i.e. 2PL-HP, PCP (Priority Ceiling

Protocol), SCC (Speculative Concurrency Control),

etc.). Our RealTimeClass stereotype overlaps with the

UML extensions presented by MARTE proﬁle espe-

cially those relative to the mailbox and the local con-

troller. In fact, a RealTimeClass may be considered

as an autonomous execution resource, able to handle

different messages at the same time. It can manage

concurrency and real-time constraints attached to in-

coming messages. This has the same meaning as the

RTUnit stereotype deﬁned in MARTE (cf. Figure 1).

Thus, we consider that the RealTimeClass concept as

a specialization of MARTE RtUnit concept. Thereby,

a RealTimeClass is a real-time unit but with a RTDB

modeling semantics. It represents the RTDB entity

which encapsulates time-constrained data and time-

constrained operations. It also deals with parallelism

and concurrency features.

4 MODELING OF TEMPORAL

ASPECTS

4.1 Time Speciﬁcation in MARTE

The sub-proﬁle TIME of MARTE has been intro-

duced to model timing aspects. Figure 3 depicts the

MARTE extension about time modeling in UML. The

Clock stereotype is a model element that represents

an instance of ClockType. The ClockType stereotype

is related indirectly to the Clock stereotype. Its prop-

erties specify the kind of clock (chronometric or log-

Figure 4: Clocks Speciﬁcation in our RTDB Proﬁle.

ical), the nature (dense or discrete) of the represented

time, a set of clock properties (e.g., resolution, max-

imal value, etc.) and a set of accepted time units.

The ClockConstraint is a stereotype of the UML Con-

straint concept. The clock constraints are used to

specify the time structure relations of a time domain.

A ClockConstraint is a constraint that imposes depen-

dency between clocks or between clock types.

4.2 Modeling of RTDB Temporal

Properties

Time is present in different RTDB features and more

specially in real-time data. Real-time data are divided

into two classes: sensor data and derived data. As pre-

viously mentioned in Section 3.2.1, we have deﬁned

for each sensor data a periodic method (i.e. period-

icUpdate) which is periodically executed to update

the values of the corresponding sensor data. In the

same way, we have deﬁned for each derived data a

sporadic method (i.e. sporadicUpdate) which is spo-

radically executed to update the values of the corre-

sponding derived data. In this section, we deﬁne for

the sensor and derived data clocks as well as their as-

sociated properties in a high level speciﬁcation using

the TIME sub-proﬁle of MARTE. The temporal unit

that we are looking for can be used in two ways: (i) to

reference the physical time and adopt a chronometric

clock for sensor data, (ii) to reference a logical time

that is incremented each time sensor data have been

updated.

The MARTE TimeLibrary provides a model for

the ideal time used in physical laws: idealClk, which

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

122

is an instance of the class IdealClock, stereotyped by

ClockType. The IdealClock represents the time evo-

lution. This time is expressed in seconds in the inter-

national system units. Starting with idealClk, we de-

ﬁne new discrete chronometric clock (cf. Figure 4).

First, we speciﬁes Chronometric (a class stereotyped

by ClockType) which is discrete, not logical (therefore

chronometric), and with a read only attribute (resolu-

tion). Clocks belong to timed domains. In Figure 4, a

single time domain is considered. It owns two clocks:

idealClk and sensorClk, an instance of Chronometric

that both uses the second (s) as a time unit; and whose

resolution is 0.01 s. The two clocks are a priori in-

dependent. A clock constraint speciﬁes relationships

among them. The ﬁrst statement of the constraint de-

ﬁnes a clock c local to the constraint. C is a discrete

time clock derived from idealClk by a discretization

relation. The resolution of this clock is 1 ms. The

next statement specify that sensorClk is subclock of

c with a rate p times slower than c. The fourth state-

ment indicate that sensorClk is not a perfect clock.

Flaws are characterized by non functional properties

like stability and offset. Its rate may have small vari-

ations (a stability of 10

−

implicitly measured on ide-

alClk). The last statement claims that the clocks is

out of phase, with an offset value between 0 and 5 ms

measured on idealClk.

Figure 4 depicts the deﬁnition of a logical clock

dedicated for derived data. We have created a class

DerivedDataClock with ClockType as stereotype.This

class has three attributes: maximalValue, offset and

resolution. MaximalValue speciﬁes the maximal

value of the associated clock, value at which the clock

rolls over. The offSet property determines the initial

instant of the associated clock. The resolution at-

tribute deﬁnes the resolution of the associated clock.

Now that we have deﬁned the clock, we need to in-

stantiate it. Figure 4 depicts the instantiation of the

clock DerivedDataClock called derivedClk. The unit

of DerivedClk is the sensor data update.

Sensor data are periodically updated causing the

update of each derived data that uses those sensor

data. This is equivalent to say that the derived data up-

date operation is activated everytick of the clock asso-

ciated with sensor data. We can deduce an afﬁne rela-

tion between sensorClk and derivedClk as speciﬁed in

the clock constraint speciﬁed in Figure 4: derivedClk

isPeriodicOn sensorClk, period = pp, offset=t. Such

a constraint states that each pp

occurrence of sen-

sorClk there will be an occurrence of derivedClk and

the ﬁrst occurrence of derivedClk appears at the t

instant of sensorClk.

5 MODELING OF BEHAVIORAL

ASPECTS

5.1 Behavior Speciﬁcation in MARTE

State machines are often used in the real-time and

embedded domain. They allow the description of a

system behavior in terms of states and transitions be-

tween these states. MARTE introduces mainly two

time-related concepts that can be used to improve the

usage of the UML behaviors, such as state machines,

for developing real-time applications: timed process-

ing and timed events (cf. Figure 3). The TimedPro-

cessing stereotype enables modelers to specify dura-

tion for a behavior. The TimedProcessing stereotype

represents activities that have known start and ﬁnish

times or a known duration, and whose instants and du-

rations are explicitly bound to clocks. It can also ref-

erence events triggered when a behavior or processing

starts and ends. The duration can be speciﬁed using

the VSL language, which supports time expressions.

The TimedEvent stereotype represents events

whose occurrences are explicitly bound to a Clock.

It extends the TimeEvent concept of UML. It allows

to characterize the logical or physical clock on which

a time event relates.

5.2 Modeling of RTDB Behavior

A RTDB is a collection of real-time objects which are

used to manage time-critical dynamic systems in the

real world. RTDB behavior model building consist of

describing the behavior with state-transition diagram

for each real-time object of the RTDB. Stereotypes

TimedProcessing and TimedEvent are used to specify

behavior, duration of a behavior, and events bounded

to a clock. The tagged value queueSchedPolicy, de-

ﬁned in MARTE, are associated to the state-transition

diagram in order to indicate the queue scheduling pol-

icy of a behavior. We apply the TimedProcessing

stereotype on the state machine itself and we spec-

ify the corresponding clock using the meta-attribute

on. We employ the TimedEvent stereotype in order to

characterize the logical and physical clocks on which

a time event relates.

6 CASE STUDY

Throughout, this section, we will use a running exam-

ple to illustrate the use of our proﬁle. We illustrate

our proposal on an air trafﬁc control system. The

aim of the air trafﬁc control is to separate aircrafts,

ModelingStructural,TemporalandBehavioralFeaturesofaReal-TimeDatabase

123

Figure 5: Aircaft real-time class.

Figure 6: Aircraft behavior modeling.

to avoid collisions and to organize the ﬂow of traf-

ﬁc. It consists of a large collection of data describ-

ing the aircrafts, their ﬂight plans, and data that re-

ﬂect the current state of the controlled environment

(Locke, 2001). This includes ﬂight information, such

as aircraft identiﬁcation, speed, altitude, origin, des-

tination, route and clearances. In fact, each aircraft

has three sensor data which are speed, altitude and

location and two derived data which are path and

lane. Sensor data are periodically updated to reﬂect

the state of an aircraft. The derived data is calcu-

lated based on altitude, location, and direction val-

ues, in order to verify if the aircraft deviates from a

predetermined path or lane. All these data values are

published periodically by sensors supervising the air-

crafts controlled elements.

For sake of clarity, only the Aircraft class and

a subset of its methods are speciﬁed. Each Air-

craft in the airspace is stereotyped by realTimeClass.

We characterize the Aircraft class by three sensor at-

tributes: direction, location, and altitude. Each at-

tribute is periodically updated in order to closely re-

ﬂect the real world state of the application environ-

ment. Thereby, we associate to each sensor attribute

a periodic method: updateAltitude(), which periodi-

cally updates the value and the timestamp of the alti-

tude. We characterize also the Aircraft class by two

derived attributes: lane which is calculated from loca-

tion and altitude values, and path, which is calculated

from location and direction values. Each derived at-

tribute has its own sporadic method: computePath(),

which sporadically updates the value and the times-

tamp of the path. Figure 5 depicts a simpliﬁed view of

the Aircraft class. We indicates that the Aircraft class

is the main unit of the application (property isMain is

set to true) and it starts a main rtService, called start().

Its isDynamic property is set to true. In this case, the

schedulable resources are created dynamically when

required. The attribute altitude has a validity dura-

tion equal to (3, s) and its maximumDataError is 5.

Additionally, it is updated periodically using the up-

dateAltitude() operation, which has a period equal to

(3, s). The concPolicy attribute of that operation is

writer and its isAtomic attribute is set to false. In

the same way, we characterize the derived attribute

path by a validityDuration and a maximumDataError

and it is sporadically updated by means of the com-

putePath() operation.

Figure 6 depicts a state-machine diagram that pro-

vides a simpliﬁed view of the Aircraft behavior. The

Aircraft has four states: TakeOff, Flying, Update, and

Landing. Periodically , it enters in the Update state

for updating the Aircraft sensors values. The sensors

values update has to be done with a period of 5 s and

lasts 2 s. Then it returns to the state which activated

the update transition. We apply the TimedProcessing

stereotype on the state machine itself. We use the for-

mer to indicate the scheduling policy associated with

the Aircraft behavior (i.e EDF). The latter is used to

assign the sensorClk clock to the model. All the el-

ements of the state machine have the same time ref-

erence. We apply the TimedEvent stereotype on the

UML timed event that triggers the UpdateTimeOut

transition.

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

124

7 CONCLUSIONS

The richness of MARTE proﬁle in terms of con-

cepts offers an interesting common modeling basis

to adequately specify many design features of RT-

DBs. In This paper, we showed how the concepts

of the MARTE standard proﬁle can serve to model

RTDB features. We used the HLAM package to de-

scribe both quantitativeand qualitativeproperties, and

the TIME sub-proﬁle to specify temporal properties.

Moreover, we proposed UML/MARTE-based exten-

sions for a complete and powerful RTDB modeling.

Additionally, the proposed extensions not only cap-

ture the structural aspects of RTDB features, but also

the temporal and behavioral aspects. We have in-

vested some efforton ensuring that all concepts havea

well deﬁned basis semantics. This has been illustrated

on a case study in the context of Air Trafﬁc Control

System.

We are currently working on the the integration

of the RTDB development process in the context of

a Model Driven Architecture. This way, the complex

task of designing the whole RTDB is tackled in a sys-

tematic, well-structured and standard manner.

REFERENCES

Agrawal, D., Bruno, J. L., Abbadi, A. E., Krishnaswamy,

V., El, A., and Krishnaswamy, A. V. (1994). Relative

serializability: An approach for relaxing the atomicity

of transactions. In In Proceedings of the 13th ACM

Symposium on Principles of Database Systems, pages

139–149. ACM.

Amirijoo, M., Hansson, J., and Son, S. H. (2006). Speciﬁ-

cation and management of qos in real-time databases

supporting imprecise computations. IEEE Trans.

Computers, 55(3):304–319.

Debnath, N., Riesco, D., Montejano, G., Grumelli, A., Mac-

cio, A., and Martellotto, P. (2003). Deﬁnition of a

new kind of uml stereotype based on omg metamodel.

In Computer Systems and Applications, 2003. Book

of Abstracts. ACS/IEEE International Conference on,

pages 49–54.

DiPippo, L. C. and Ma, L. (2000). A uml package for spec-

ifying real-time objects. Comput. Stand. Interfaces,

22:307–321.

Idoudi, N., Duvallet, C., Sadeg, B., Bouaziz, R., and

Gargouri, F. (2008a). Structural model of real-time

databases. In ICEIS (3-2), pages 319–324.

Idoudi, N., Duvallet, C., Sadeg, B., Bouaziz, R., and

Gargouri, F. (2008b). Structural model of real-time

databases: An illustration. In ISORC, pages 58–65.

Idoudi, N., Louati, N., Duvallet, C., Sadeg, B., Bouaziz, R.,

and Gargouri, F. (2010). A framework to model real-

time databases. International Journal of Computing

and Information Sciences (IJCIS), 7(1):1–11.

Locke, C. D. (2001). Applications and system characteris-

tics. In Real-Time Database Systems, pages 17–26.

OMG (2009). A UML Proﬁle for MARTE: Modeling and

Analysis of Real-Time Embedded systems, version

1.0, formal/2009-11-02.

Ramamritham, K. (1993). Real-time databases. Distributed

and Parallel Databases, 1(2):199–226.

Ramamritham, K. and Pu, C. (1995). A formal characteriza-

tion of epsilon serializability. IEEE Trans. on Knowl.

and Data Eng., 7:997–1007.

Ramamritham, K., Son, S. H., and DiPippo, L. C. (2004).

Real-time databases and data services. Real-Time Sys-

tems, 28(2-3):179–215.

Stankovic, J. A., Son, S. H., and Hansson, J. (1999). Mis-

conceptions about real-time databases. IEEE Com-

puter, 32(6):29–36.

ModelingStructural,TemporalandBehavioralFeaturesofaReal-TimeDatabase

125