STR

UCTURAL MODEL OF REAL-TIME DATABASES

∗

Nizar Idoudi, Claude Duvallet, Bruno Sadeg

LITIS, UFR des Sciences et Techniques, 25 rue Philippe Lebon BP 540, 76 058, Le Havre Cedex, France

Raﬁk Bouaziz, Faiez Gargouri

MIRACL-ISIMS, BP 1030, 3018, Sfax, Tunisie

Keywords:

RTDB, Real-Time Objects, Sensor Attributes, Derived Attributes, Evolutionary Stereotype, UML proﬁle.

Abstract:

A real-time database is a database in which both the data and the operations upon the data may have timing

constraints. Our objective in this paper is to model easily real-time database structures using the Model-Driven

Engineering paradigm, specially the UML2 language. For that purpose, we propose an UML2.0 proﬁle,

entitled UML-RTDB, which is based on UML2.O Proﬁles package, in order to cope with the speciﬁc need of

designing real-time databases.

1 INTRODUCTION

A real-time database is a database in which both

the data and the operations upon the data may have

timing constraints (Ramamritham, 1993). Real-time

database operations involve gathering data from the

environment, processing the gathered information in

the context of previously acquired information, and

providing timely responses. The operations also in-

volve processing not only archival data but also tem-

poral data which loses its validity after a certain time

duration. Timing constraints of data express how old

data can still be considered valid. In general, tempo-

ral consistency of data has two aspects: absolute and

relative. The absolute temporal consistency restricts

the age of a single data item, while relative tempo-

ral consistency restricts the relative ages of a groups

of data items with respect to each other (Ramam-

ritham, 1993). Both the time semantics of the data

and the response-time requirements imposed by the

environment deﬁne the transaction timing constraints

and may be expressed as either the periods or dead-

lines.

Two of the most widely-studied models for real-

time databases are the relational and the object-

oriented models. However, due to the nature of many

∗

This

work is supported by the Haute-Normandie region

CPER project “Logistic Transport Network and Informa-

tion Technics”.

real-time applications that must handle complex real-

world objects with short deadlines, many researchers

believe that the object-oriented model is more natural

and powerful than the relational model (Kim, 1995).

Several research projects on real-time databases have

adopted the object-oriented model for building their

prototype systems (Wolfe et al., 1997) (Stankovic

et al., 1997). Our work in this paper is based on

the object-oriented database model. Thus, a real-

time database is a collection of objects which are used

to model time-critical dynamic systems in the real

world. Each object has some internal state which is

protected by the object abstraction. The only way that

objects can be accessed by transactions is to invoke

the methods deﬁned by objects.

UML is a general language for modeling object-

oriented applications across a wide range of domains.

Developing a truly adequate uniform modeling lan-

guage in the face of these diverse domains seems an

unsolvable quest and contrasts domain speciﬁc soft-

ware engineering activities. Recently, many adapta-

tions to the UML have been made to reﬂect a real-

time domain’s world. Thereby, several UML ap-

proaches were proposed to take into account the real-

time system requirements such as RT-UML (Dou-

glass, 2004), UML-SDL (ITU-T, 1999), and AC-

CORD/UML (Lanusse et al., 1999). In the UML

standard, The basic concepts which are integrated

are those of RT-UML, through the UML proﬁle for

319

Idoudi N., Duvallet C., Sadeg B., Bouaziz R. and Gargouri F. (2008).

STRUCTURAL MODEL OF REAL-TIME DATABASES.

In Proceedings of the Tenth International Conference on Enterprise Information Systems - ISAS, pages 319-324

DOI: 10.5220/0001704403190324

 SciTePress

Schedulability, Performance, and Time (denoted SPT

proﬁle) (OMG, 2005). However, UML constructs

used by these approaches do not support real-time

database requirements. Indeed, the design of real-

time database must consider both temporal aspects of

data and timing constraints of transactions (Stankovic

et al., 1999). To the best of our knowledge, there is

only one based UML proposal for real-time databases

modeling (DiPippo and Ma, 2000). In their work, the

authors have deﬁned an UML package for specifying

RTSORAC object, called RT-Object. However, the

RT-Object package is based on the Extension Mecha-

nisms package of UML1.3 which is a past standard.

The organisation of this paper is as follows. Sec-

tion 2 describes our real-time object model. Section

3 details the UML-RTDB proﬁle, which is a special-

ized variant of the UML2.0 in real-time database ap-

plications. This proﬁle contains specialized versions

of the metamodel elements, i.e. Stereotypes, deﬁned

in the UML2.0 metamodel that allow the design of

class diagrams for real-time databases. In section 4,

we conclude the paper and give some perspectives to

our work.

2 REAL-TIME OBJECT MODEL

A real-time database is by deﬁnition a database sys-

tem. It has queries, schemas, transactions, com-

mit protocols, concurrency control support, and stor-

age management (Stankovic et al., 1999). A real-

time database models an external environment that

changes continuously. It is designed to be kept in

shared main memory for fast and predictable access

(Ramamritham, 1993). The design of a real-time

database has to take into account the management of

all these components. That’s why, in our work, we

deﬁne a Real-time object in order to declare the time-

constrained data, the time-constrained operations, the

parallelism, and the concurrency property inherent to

real-time databases. Real-time objects are real-time

database entities. They represent dynamic entities of

time-critical dynamic systems in the real world. As

shown in the ﬁgure 1, each real-time object is made

of four components: (i) a set of real-time attributes,

(ii) a set of real-time methods, (iii) a mailbox, and

(iv) a local controller.

Because of the dynamic nature of the real world,

more than one transaction may send requests to the

same real-time object. Concurrent execution of these

transactions allows several methods to run concur-

rently within the same object. To handle this essential

property of real-time database systems, we associate

to each real-time object a local concurrency control

Real−time

methods

Real−time

attributes

Local Controller

Method1 ()

Method3 ()

Method2 ()

Real−time object

Mailbox

Method3 ()

Method1 ()

Method2 ()

External

interface

Messages

Figure 1: Schema of the Real-time object.

mechanism, named local controller, that manages the

concurrent execution of its methods. Thus, the real-

time object receives messages in its mailbox awaking

its local controller that checks the timing constraint

attached to messages and selects one message follow-

ing a special scheduling algorithm. The local con-

troller veriﬁes the concurrency constraints with the al-

ready running methods of the real-time 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. If the service is periodic, the

thread is not released and supports all periodic exe-

cution of the requested service. A real-time object

is an extension of active object as usually deﬁned

in concurrent programming languages (Terrier et al.,

1997), that encapsulates time-constrained data, time-

constrained methods and concurrency control mecha-

nisms.

2.1 Sensor and Derived Attributes

Real-time data is divided into two types: sensor data

and derived data (Ramamritham et al., 2004). Sensor

data are the data issued from sensors. Derived data

are the data calculated from sensor data. Our real-

time data model is based on the model introduced in

(Ramamritham, 1993) and we associate to this model

the notion of maximum data error (MDE) introduced

in (Amirijoo et al., 2006). Thus, a real-time data is

modeled by d = (d

value

, d

timestamp

, d

avi

, d

mde

), where

value

represents the real world data value, d

timestamp

is the time at which the attribute’s value was last up-

dated, d

avi

is the absolute validity interval and d

mde

the maximum amount of imprecision associated with

the attribute’s value.

We characterize the real-time object by a real-time

attribute model, which is devided into two types of

attributes: sensor attributes and derived attributes.

Senor attributes are used to store a sensor data which

must be periodically updated in order to closely re-

ﬂect the real world state of the application environ-

ICEIS 2008 - International Conference on Enterprise Information Systems

320

ment. Derived attributes are used to store a derived

data that has to be calculated from sensor attributes.

Name

Current Value

(CV)

TimeStamp

(TS)

Validity Duration

(VD)

Maximum Data Error

(MDE)

Figure 2: Structure of the Real-time attribute.

As shown in the ﬁgure 2, each real-time attribute

is characterized by <N, CV, TS, VD, MDE>. N is the

name of the attribute. The second ﬁeld, CV, is used

to store the ﬁnal attribute value captured by the last

update correspondent method. This ﬁeld is used by

the system to determine logical integrity constraints

of the attribute value. The third ﬁeld, TS, is used to

store the time at which the attribute’s value was last

updated (Ramamritham, 1993). Access to the times-

tamp of an attribute is necessary for determining tem-

poral consistency of the attribute. The next ﬁeld, VD,

is used to store the absolute validity interval (denoted

by avi) of the attribute value (Ramamritham, 1993).

It represents the amount of time during which the at-

tribute value is considered valid. This element is nu-

meric and permits to determine, in association with

TS, the absolute consistency of the attribute (Ramam-

ritham, 1993). The last ﬁeld, MDE, of a real-time

attribute is used to memorize the absolute maximum

data error tolerated on the attribute value (Amirijoo

et al., 2006). This ﬁeld determines the upper bound

of deviation between the current data value and the

updated value.

3 AN UML-RTDB PROFILE

There is a need to deﬁne an UML proﬁle supporting

real-time database requirements. In this section, we

present an UML proﬁle, entitled UML-RTDB, which

is based on UML2.0 Proﬁles package and provides

various stereotypes for sensor attributes, derived at-

tributes and real-time objects.

3.1 Real-Time Attribute Stereotype

The main goal of the UML-RTDB is to provide to

the designers of real-time databases an UML exten-

sion (stereotypes) that supports both sensor and de-

rived attributes features. A stereotype deﬁnes how

an existing metaclass may be extended, and enables

the use of platform or domain speciﬁc terminology

or notation, in addition to the ones used for the ex-

tended metaclass (OMG, 2007). However, the stan-

dard stereotype can not express features of sensor and

derived attributes because it does not allow the deﬁ-

nition of structural and behavioral features (Debnath

et al., 2003). Besides, the ﬁelds timestamp, valid-

ity duration and maximum data error represent struc-

tural features and should be expressed as Attributes.

Each atribute is also characterized by an update oper-

ation that ensures its freshness and must be modeled

as an Operation. For this reason, we base our work

on the Evolutionary Stereotype extension mechanism

of UML (Debnath et al., 2003). This extension mech-

anism allows the deﬁnition of new stereotypes with

structural and behavioral characteristics.

Moreover, we base our proposal on the Extension

relationship proposed in UML2.0 Proﬁles package

(OMG, 2007). The extension is used to indicate that

the properties of a metaclass are extended through a

stereotype, and gives the ability to ﬂexibly add (and

later remove) stereotypes to (resp. from) classes.

Thus, the Stereotype::baseClass attribute is replaced

by an extension relationship to the Class metaclass.

This former generalizes the Stereotype metaclass and

contains a name attribute. In addition, the Stereo-

type::icon attribute is replaced by the icon role linking

the Stereotype metaclass to Image metaclass.

Since the sensor attributes and derived attributes

have the same structural characteristics (Timestamp,

Validity Duration, Maximum Data Error) and behav-

ioral characteristics (Update operation), we propose

an abstract stereotype, called ¿RealTimeAttributeÀ,

in order to factorize these characteristics. So, in-

stead of deﬁning the structural and behavioral features

for each stereotype aside, we deﬁne these features in

a general manner within the ¿RealTimeAttributeÀ

stereotype. This former is a realization of the Evolu-

tionary stereotype that allows the statement of struc-

tural and behavioral features. Thereby, as shown

in ﬁgure 3, the ¿RealTimeAttributeÀ stereotype

is characterized by three structural and one behav-

ioral characteristics. The ﬁrst features are deﬁned

by TimeStamp, Validity Duration, and Maximum

Data Error metaclasses, which specialize the Struc-

turalFeature metaclass of UML metamodel. The last

feature is deﬁned by the Update metaclass, which spe-

cializes the BehavioralFeature metaclass.

The TimeStamp metaclass declares the timestamp

of the attribute. It is characterized by two proper-

ties: Type and Granularity, where Type indicates the

type of the Timestamp value, which is the Time type

expressed in UML metamodel. The Granularity de-

ﬁnes the granule of the Timestamp, which may be

“Minute”, “Second”, etc.

The Validity Duration metaclass deﬁnes the valid

time of the attribute value. It is characterized by two

properties: Type and Granularity. The Type indi-

STRUCTURAL MODEL OF REAL-TIME DATABASES

321

Feature

Image

Class

name : string [0..1]

Stereotype

StructuralFeature

Extension relationship

0..1

icon

Real−Time Attribute

newFeature

Type: Time

TimeStamp Maximum Data Error

Type: String

Validity Duration

Type: Integer

Granularity: String Granularity: StringGranularity: String

BehavioralFeature

Update

Type: String

Figure 3: Abstract syntax of the ¿RealTimeAttributeÀ stereotype.

:Class

:Stereotype

:StructuralFeature

:Feature

:Update

:Feature

:Real−Time Attribute

:Class

:Timestamp :Validity Duration :Maximum Data Error

: Image

:BehavioralFeature

Name: "Attribute"

NewFeature

Type: Time Type: Integer

Granularity: "Second"

Type: Integer

Granularity: "Second"

Name: "Sensory"

Extension relationship

Granularity: "Second"

Type: "Periodic"

Figure 4: Abstract syntax of the ¿SensoryÀ stereotype.

cates the type of the Validity Duration value, which

is typed Integer. The Granularity deﬁnes the gran-

ule of the Validity Duration, which may be “Minute”,

“Second”, etc.

The Maximum Data Error metaclass deﬁnes the

amount of error tolerated on an attribute value. It

contains a Type property, which indicates the type of

Maximum Data Error value. It has the same type as

attribute value. A Granularity property deﬁnes the

granule of the Maximum Data Error, which may be

“Minute”, “Second”, etc.

The Update metaclass declares the operation

which updates the CurrentValue and TimeStamp

ﬁelds of the attribute. It contains a Type property that

indicates the type of the operation periodicity. In our

case, the operation periodicity depends on the type of

the attribute. It is “Periodic” for a sensor attribute,

and it is “Sporadic” for a derived attribute.

3.2 Sensory and Derived Stereotypes

We deﬁne ¿SensoryÀ stereotype and ¿DerivedÀ

stereotype to declare respectively sensor attributes

and derived attributes, in the structural model.

Each stereotype presents a realization of the

¿RealTimeAttributeÀ stereotype according to the

appropriate values of its properties, and an extension

of the Attribute metaclass of UML metamodel.

Figure 4 shows the abstract syntax of ¿SensoryÀ

stereotype. Its structural features are declared by

the metaclasses: TimeStamp, Validity Duration, and

Maximum Data Error. In this work, we consider that

time granularity is the “Second”. The designers of

real-time databases can easily modify the values of

stereotype properties according to the requirements

of real-time applications. The only behavioral feature

of the ¿SensoryÀ stereotype is deﬁned by the

Update metaclass. The ¿DerivedÀ stereotype has

the same abstract syntax as the ¿SensoryÀ stereo-

ICEIS 2008 - International Conference on Enterprise Information Systems

322

Validity DurationMaximum Data Error

TimeStamp

Update

<<Sensory>>

600

Type: Integer

Granularity: "Second"Granularity: "Second"

Type: Integer

Granularity: "Second"

Type: Integer

<<instanceOf>>

Metamodel

(M2)

10:25:2

5 20

Speed: Integer

Model

(M1)

Instance model

(M0)

Figure 5: Instance Model of the ¿SensoryÀ stereotype.

Aircraft

Identifier

Destination

SetIdentifier ( )

GetLane ( )

Name

Lane

Direction

Location

Path

UpdateAltitude ( )

ComputePath ( )

Operations

Attributes

<<RealTimeObject>>

Figure 6: Aircraft real-time object class.

type. They have the same structural and behavioral

characteristics. Besides, they extend the same meta-

instance of the Class metaclass, i.e. “Attribute”,

through the Extension relationship. However, these

two stereotypes differ in their speciﬁc notations,

their meta-instances of the Class metaclass which

generalizes the Stereotype metaclass and speciﬁes

the name of the stereotype, and their operations

periodicity. So, for the ¿SensoryÀ stereotype,

the meta-instance name of the Class metaclass is

“Sensory” (cf. ﬁgure 4). For the ¿DerivedÀ

stereotype, the meta-instance name is “Derived”.

Besides, as shown in the ﬁgure 6, we have chosen a

“watch” as an icon declaring a sensor attribute and a

“Calculator” declaring a derived attribute. The oper-

ation periodicity of a sensor attribute is “Periodic”

and it is “Sporadic” for a derived attribute.

Figure 5 shows an instance model of the sensor at-

tribute Speed, according to three layers: metamodel,

users model, and user objects (user data). It is charac-

terized as follows:

¿Name: Speed, CurrentValue: 600, TimeStamp:

10:25:2, ValidityDuration: 20, MaximumDataError:

5À.

3.3 Real-Time Object Stereotype

A real-time database is a collection of real-time ob-

jects which are used to model a time-critical dy-

namic system in the real world. The design of a

real-time database has to take into account the man-

agement of real-time object features. In our work,

we deﬁne a ¿RealTimeObjectÀ stereotype in or-

der to declare the time-constrained data, the time-

constrained operations, the parallelism, and the con-

currency property inherent to real-time objects. The

¿RealTimeObjectÀ stereotype is added to classes in

order to specify that their instances will encapsulate

real-time data, real-time operations, and a local con-

currency control mechanism.

As an example, we consider an air-trafﬁc con-

trol system (Locke, 2001), in which each aircraft in

the airspace can be modeled as a real-time object.

The designers of the system can include the UML-

RTDB package when building their design in order

STRUCTURAL MODEL OF REAL-TIME DATABASES

323

to cope with the speciﬁc need of designing real-time

databases. Figure 6 illustrates an Aircraft real-time

object class. It encapsulates classical and real-time

attributes (sensor and derived), and real-time opera-

tions.

4 CONCLUSIONS AND FUTURE

WORK

In this work, we have presented how to represent real-

time related properties in the object-oriented worlds,

such as object-oriented databases and object-oriented

CASE tools, such as UML2.0. For this purpose, we

have proposed a real-time object model to include

real-time aspects within databases from the viewpoint

of object-oriented data model instead of traditional

relational data model. We have also proposed an

UML proﬁle, called UML-RTDB, which is based on

UML2.0 Proﬁles package and which provides various

stereotypes for sensor attributes, derived attributes,

and real-time objects.

In our future work, we will illustrate our pro-

posal on an air trafﬁc control system, as proposed in

(Locke, 2001). We will also extend UML-RTDB with

other stereotypes in order to express time-constrained

operations, time-constrained associations, and time-

constrained multiplicities.

REFERENCES

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

Speciﬁcation and management of QoS in real-time

databases supporting imprecise computations. IEEE

Transactions on Computers, 55(3):304–319.

Debnath, N., Riesco, D., Maccio, A., Montejano, G.,

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

kind of UML stereotype based on OMG metamodel.

In Proceedings of the ACS/IEEE Arab International

Conference on Computer Systems and Applications:

AICCSA’03, Tunis, Tunisia.

DiPippo, L. C. and Ma, L. (2000). A UML package for

specifying real-time objects. Computer Standards and

Interfaces, 22(5):307–321.

Douglass, B. (2004). Real Time UML, Third Edition : Ad-

vances in The UML for Real-Time Systems. Pearson

Education, Inc, 0-321-16076-2.

ITU-T (November 1999). Recommendation Z.109: lan-

guages for telecommunications applications - SDL

combined with UML. International Telecommunica-

tion Union.

Kim, W. (1995). Object-Oriented Database Systems:

Promises, Reality, and Future. Modern Database Sys-

tems, pages 255–280. Addison Wesly.

Lanusse, A., G

erard, S., and Terrier, F. (1999). Real-time

modeling with UML: The ACCORD approach. In

ezivin, J. and Muller, P.-A., editors, The Uniﬁed

Modeling Language, UML’98 - Beyond the Notation.

First International Workshop, Mulhouse, France, June

1998, Selected Papers, volume 1618 of LNCS, pages

319–335. Springer.

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

tics. In Real-Time Database Systems: Architecture

and Techniques, pages 17–26. Kluwer Academic Pub-

lishers.

OMG (January 2005). ”UML Proﬁle for Schedulability,

Performance and Time, v1.1”, formal/2005-01-02.

OMG (November 2007). ”Uniﬁed Modeling Language

(UML), Infrastructure, v2.1.2”, formal/2007-11-04.

Ramamritham, K. (1993). Real-Time Databases. Journal

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

Ramamritham, K., Son, S., and DiPippo, L. (2004). Real-

Time Databases and Data Services. Real-Time Sys-

tems, 28:179–215.

Stankovic, J., Son, S., and Hansson, J. (1999). Miscon-

ceptions about real-time databases. IEEE Computer,

32(6):29–36.

Stankovic, J., Son, S., and Liebeherr, J. (1997). BeeHive:

Global Multimedia Database Support for Dependable,

Real-Time Applications. In Real-Time Database and

Information Systems, pages 409–422. Kluwer Aca-

demic Publishers.

Terrier, F., Lanusse, A., Bras, D., Roux, P., and Vanux-

eem, P. (1997). Concurrent object for multitasking.

In L’objet, volume 3, pages 179–196, Paris, France.

Wolfe, V. F., Prichard, J. J., Dipippo, L. C., and Black,

J. (1997). Real-Time Database System: Issues

and Applications, chapter The RTSORAC Real-Time-

Object-Oriented DataBase Prototype, pages 279–301.

Kluwer Academic Publishers.

ICEIS 2008 - International Conference on Enterprise Information Systems

324