Object-oriented Real-time Database Design based on Description Logics

Zied Ellouze

, Nada Louati

and Raﬁk Bouaziz

CES-ENIS, Sfax University, BP 1173, 3038, Sfax, Tunisia

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

Keywords:

Data Model, Real-time, Database, Description Logic.

Abstract:

This paper proposes a Description Logics based data model of a real-time object-oriented database. It allows

the modeling of structural and behavioral aspects related to the objects in a real-time database. This model

provides designers a data model where they can specify both temporal aspects of data and timing constraints

on transactions as well as concurrency control mechanisms.

1 INTRODUCTION

A real-time database is a time-constrained database

designed to handle not only transactions with timing

constraints, but also data with timing constraints (Ra-

mamritham, 1993). The timing constraints on data are

deﬁned as how well the content of the database mod-

els the actual state of the real world while the timing

constraints on transactions are expressed in the form

of deadlines which indicate a certain time in the future

by which the transactions must be completed. In gen-

eral, there are two forms of data timing constraints:

absolute and relative. The absolute timing constraint

requires that a data item’s age must be within a cer-

tain interval of the current time. The relative timing

constraint represents the required correlation among

data used together (Ramamritham, 1993). Real-time

databases require also enforcement of the temporal

consistency of transactions in addition to their logi-

cal consistency. Transaction logical consistency con-

strains the values of results produced by transactions,

while transaction temporal consistency requires that

transactions be treated as real-time tasks with timing

constraints.

Conventional data models are not suitable for

time-critical applications, since there is no mecha-

nism to deal with time constraints. They are de-

signed to get a good throughput or response time.

Very few of them permit users to specify timing con-

straints. Several works have used the relational model

as a data model for real-time databases (Ramam-

ritham, 1993). Although the relational model is ad-

equate for many applications, several researchers be-

lieve that is not suitable for real-time applications that

must handle complex real-world objects with timing

constraints (Ramamritham et al., 2004). Thereby,

the real-time database community has migrated to-

wards object-oriented technology. Several research

projects have proposed object-oriented data mod-

els for real-time databases (Prichard et al., 1994),

(Lee et al., 1994), (Perkusich et al., 1995), (Taina

and Raatikainen, 1997), (Stankovic and Son, 1998),

(Idoudi et al., 2010), and (Louati et al., 2011).

The data models available to object-oriented real-

time designers vary in their representational and anal-

ysis strengths. This is mainly due to the inherent am-

biguity in the existing means of describing them (i.e.

textual and graphical). Hence, there is a dire need to

introduce formalism in order to describe them accu-

rately and allow rigorous reasoning about them. The

main problem of existing real-time object-oriented

data models is their lack of completeness and anal-

ysis. This is essentially because they tend to concen-

trate on specifying either the structural or behavioral

features of data models but not both of them. In addi-

tional, most real-time object-oriented data models are

informally deﬁned so make error-prone and difﬁcult

to analyze. Formal speciﬁcation of real-time object-

oriented data models can enhance the understanding

of their semantics. It can be used to help designers

to implement formal analysis and veriﬁcation on the

systems described by them. In this paper, we pro-

pose a Formal Real-Time Object-Oriented (F-RTOO)

data model based on Description Logics (DL). This

model provides designers a data model where they

can specify both temporal aspects of data and tim-

ing constraints on transactions as well as concurrency

control mechanisms. Additionally, it combines the

264

Ellouze Z., Louati N. and Bouaziz R..

Object-oriented Real-time Database Design based on Description Logics.

DOI: 10.5220/0004453502640271

In Proceedings of the 15th International Conference on Enterprise Information Systems (ICEIS-2013), pages 264-271

ISBN: 978-989-8565-59-4

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

formal speciﬁcation of structural and behavioral as-

pects of real-time object-oriented data models in one

speciﬁcation.

The structure of the rest of this paper is as follows.

Section 2 discusses the related work. Section 3 pro-

vides background information on the DL. Section 4

describes our F-RTOO data model. Section 5 presents

a case study, and ﬁnally in Section 6 the conclusion is

presented.

2 RELATED WORKS

In recent years, several works on real-time databases

have been proposed to deal with data modeling issues.

Only a few of these works address real-time object-

oriented data modeling.

DiPippo and Ma (Prichard et al., 1994) describe

the RTSORAC model which qualiﬁes the basic pa-

rameters for modeling a real-time database object-

oriented data model. It is composed of three com-

ponents: objects, relationships, and transactions.

In (Lee et al., 1994), Lee et al. describe a simple

real-time object-oriented data model with atomic ob-

jects and a class manager. Atomic objects are basic

entities that ensure atomicity of transactions. Class

manager is the major vehicle that lessens the com-

plexity involved in transaction management.

The G-CPN (Perkusich et al., 1995) model allows

the modeling of syntactical and semantical features

related to the objects in a real-time database. The se-

mantical features can be mapped to Petri net construc-

tions. G-CPN model has introduced extensions in an

object colored Petri net to model a real-time database.

The RODAIN (Taina and Raatikainen, 1997)

model is a real-time object-oriented database archi-

tecture for intelligent networks. It supports two kind

of attributes: regular and real-time. A real-time object

has predeﬁned attributes for isolation level and access

type. It is referenced by real-time transactions that

have an explicit deadlines.

The BeeHive (Stankovic and Son, 1998) model

extends traditional object-oriented data models by in-

corporating semantic information regardingreal-time,

importance, security, fault-tolerance, and QoS re-

quirements. The BeeHive object model has some sim-

ilarity in terms of the structure of objects to the RT-

SORAC object model (Prichard et al., 1994). One of

the main differences is that while RTSORAC model

holds only real-time and approximation requirements,

BeeHive model supports a rich set of types of require-

ments and their trade-offs.

In (Idoudi et al., 2010), Idoudi et al. describe

a real-time object-oriented data model where objects

contain a set of real-time attributes, a set of real-time

methods, a mailbox, and a local controller. In (Idoudi

et al., 2010), the data model offers solutions to man-

age data and transactions characteristics and concur-

rency. But, it does not describe the schedulability as-

pect.

The RTO-RTDB (Louati et al., 2011) model is a

real-time object oriented database model that encap-

sulates time-constrained data, time-constrained trans-

actions, and concurrency control mechanisms. It pro-

vides a very rich concepts for modeling both struc-

tural and behavioral features of a real-time database.

However, it is difﬁcult to analyze and validate the

real-time database based applications it describes be-

cause of lacking precise semantics.

Table 1 presents complete analysis of different

real-time object-oriented data models presented in

this paragraph. They have mostly been described us-

ing textual (Prichard et al., 1994), (Lee et al., 1994),

(Taina and Raatikainen, 1997), (Stankovic and Son,

1998), and (Idoudi et al., 2010) or graphical (Louati

et al., 2011) notations which are not easily understood

by an inexperienced designer. This leads to complica-

tions in incorporating data model concepts effectively

into the modeling of a new application. To remediate

to this difﬁculty, the solution is using an expressive

notation based on DL to specify data models. This

improves the data model speciﬁcation quality because

DL have very strong ability of representation and de-

duction (Baader et al., 2003).

3 A BRIEF OVERVIEW OF THE

DESCRIPTION LOGICS

DL are considered the most important unifying for-

malism for the many object-oriented representation

languages used in areas other than Knowledge Repre-

sentation. These languages are equipped with a logic-

based semantics (Baader et al., 2003).

3.1 Notational Conventions

The architecture of a knowledge representation sys-

tem based on DL is composed of two parts: TBox

and Abox. The TBox contains intensional knowl-

edge in the form of a terminology and is built through

declarations that describe general properties of con-

cepts. The ABox contains extensional knowledge that

is speciﬁc to the individuals of the domain of dis-

course. TBox and ABox are deﬁned by a description

language. Elementary descriptions of description lan-

guage are atomic concepts and atomic roles (Baader

et al., 2003). In deﬁning the concept name by DL, it

Object-orientedReal-timeDatabaseDesignbasedonDescriptionLogics

265

Table 1: Tabular comparison of different object-oriented data models against RTDBs features.

Data Transactions

Data Model

Logical Consistency

Absolute Temporal Consistency

Relative Temporal Consistency

Absolute Timing Constraints

Periodic Timing Constraints

Relative Timing Constraints

Scheduling

Concurrency Control

Quality of Service

Formal Semantics

RTSORAC (Prichard et al., 1994) × × × × × × ×

EOODM (Lee et al., 1994) × × × × ×

G-CPN (Perkusich et al., 1995) × × × × × ×

RODAIN (Taina and Raatikainen, 1997) × × × ×

BeeHive (Stankovic and Son, 1998) × × × × × × ×

RTO (Idoudi et al., 2010) × × × × × × ×

RTO-RTDB (Louati et al., 2011) × × × × × × ×

is started with an uppercase letter and then followed

by the lowercase letter. Roles name starts with a low-

ercase letter.

We introduce now a description language, in

which concepts and roles are formed according to the

following syntax rule:

C, D → A|; Atomic concept

⊤|; Universal concept

⊥ |; Bottom concept

¬A|; Atomic negation

C⊓ D|; Intersection

C⊔ D|; Union

∀R.C|; Value restriction

∃R.T|; Limited exitential quantification

⊑ R

|; Role value map

3.2 Element of Object-oriented Data

Model Formalization

In this section, we ﬁrst deﬁne our model of an object-

oriented database. Then we formalize it using the de-

scription language proposed in (Efrizoni et al., 2010).

An object-oriented data model is a collection of

classes and instances of these classes. Both instances

and classes are referred to as objects. A class deﬁnes a

set of attributes and a set of operations. In this model,

the inheritance of properties (i.e. attributes and opera-

tions) is allowed. A relationship between two or more

classes is represented by an association. This latter

may be a binary association, a n-ary association, an

aggregation or a composition. In the following C(x):

denotes the name x of a class; a(x) denotes the name

x of an attribute, T(y) denote the type of an attribute,

P(x) denotes the name x of an operation of a class,

and r

denotes the name x of a role of an association.

• Class. A class is a main concept of object-oriented

data model which is used to store and manage in-

formation.

∀x,y.C(x) ⊑ ∀a(x).T(y) ⊓ P(x)

• Attribute. It represents the structural feature of a

class. It describes the state of an instance of an

object.

∀x,y.C(x) ⊑ ∀a(x).T(y)

• Operation. It represents the behavioral feature of

a class.

∀x,y.C(x) ⊑ ∀P

f(x).y

(y) ⊓ (i 6 P

f(x).y

6 j)

for i, j ∈ 1···n

• Association. It expresses the way classes collabo-

rate.

A ⊑ ∃r

⊓ ∃r

⊤ ⊑ ∀A.C

⊓ ∀A

) ⊑ (a 6 r

.A 6 b)

) ⊑ (c 6 r

.A 6 d)

• Aggregation. It can occur when a class is a col-

lection or container of other classes.

∀x

) ⊑ (> 1A)

∀x

) ⊑ (1 6 A

6 1)

ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems

266

• Composition. It represents an instance of a class

that become a part of instance of another class. It

indicates that sometimes an object is made up of

other objects.

∀x.C

(x) ∈ C(x) ⊔ ∀x.¬C(x) ∈ C

(x)

• Generalization. It depicts that one class is identi-

ﬁed as the super class and the others as subclasses

of it. Every instance of each subclass is also an

instance of the super class.

∀x.C

(x) ⊑ C(x) for i ∈ 1·· ·n

C ⊑ C

⊔C

⊔ ···C

4 A FORMAL REAL-TIME

OBJECT-ORIENTED DATA

MODEL

A real-time database manipulates real-time data

and executes real-time transactions (Ramamritham,

1993). Real-time data are divided into two types: sen-

sor data and deriveddata. Sensor data are periodically

collected from the physical environment through sen-

sors, whereas derived data, they are computed from

sensor data. When a sensor data item changes, all

derived data items that are based on it need to be re-

computed. Real-time transactions are classiﬁed into

two categories: update transactions which are used

to update values of real-time data in order to reﬂect

the state of the real world and user transactions which

represents user requests (Ramamritham et al., 2004).

Update transactions are executed periodically to up-

date sensor data, or sporadically to update derived

data. User transactions arrive aperiodically. Given the

added dimension of time on data and transactions, two

of the interesting areas of study in real-time databases

are that of transactions scheduling and concurrency

control policies. Not only the schedule must meet

timing constraints of transactions, it must also main-

tain data temporal consistency.

Hence, a real-time data model should provides

support for specifying timing constraints on data and

transactions, semantics of real-time data and real-time

transactions, and scheduling and concurrency control

mechanisms. The next subsections, proposes a formal

real-time object-oriented data model, called F-RTOO,

that supports these concepts.

The F-RTOO data model includes features that

support the requirements of a real-time database into

an extended object-oriented data model. It has a main

component that models the properties of a real-time

object-oriented database which is real-time object.

Figure 1: Aircraft real-time object.

Real-time objects represent real-time database enti-

ties. Figure 1 illustrates an example of an Aircraft

real-time object for storing information about an air

trafﬁc control system in a database.

4.1 Real-time Attribute

Data objects are classiﬁed into either non real-time

or real-time data (Ramamritham et al., 2004). A non

real-time data is a classical data that does not become

outdated due to the passage of time, whereas a real-

time data has a validity interval beyond which it be-

come useless.

The F-RTOO data model deﬁnes two types of at-

tributes: classical attributes and real-time attributes.

A classical attribute is used to store a non real-time

data, while a real-time attributestores a real-time data.

In DL assertions a real-time attribute is stated as fol-

low:

∀x,y,RTA(x) ⊆ ∀n(x).string(y)

∀x,y,RTA(x) ⊆ ∀t(x).string(y)

∀x,y,RTA(x) ⊆ ∀m(x).integer(y)

∀x,y,RTA(x) ⊆ ∀v(x).string(y)

∀x,y,RTA(x) ⊆ ∀va(x).real(y)

Object-orientedReal-timeDatabaseDesignbasedonDescriptionLogics

267

∀x,y,RTA(x) ⊆ ∀ti(x).dateTime(y)

∀x,y,RTA(x) ⊆ ∀va(x).real(y)

∀x,y,RTA(x) ⊆ ∀ti(x).dateTime(y)

∀x,y,RTA(x) ⊆ ∀vd(x).duration(y)

∀x,y,RTA(x) ⊆ ∀mde(x).real(y)

∀x,y,RTA(x) ⊆ ∀uo(x).RTO(y)

∀x,y,RTA(x) ⊆ ∀nv(x).integer(y)

• N (Name): is the name of the attribute.

• T (Type): is the type of the attribute which can be

integer, real, string, etc.

• M (Multiplicity): indicates how kinds of values or

objects a real-time attribute can obtain.

• V (Visibility): represents the visibility of the at-

tribute: public, protected or private.

• Va (Value): is used to store the real world attribute

value captured by the last update correspondent

method. This ﬁeld is used by the system to de-

termine the logical consistency constraints of the

attribute value.

• Ti (Timestamp): is used to store the instant at

which the attribute value was last updated. The

timestamp determines the temporal consistency

constraint of the attribute value. For example, in

the Aircraft real-time object, there is a property

for storing the speed, called speed, to which a

sensor periodically provides readings. This up-

date is expected every 30 seconds, thus the speed

property is considered temporally inconsistent if

the update does not occur within that time. The

timestamp value of the speed property must be

utilized by the real-time database system to deter-

mine that the update operation did not happen as

expected. There are many ways to deﬁne times-

tamps (Idoudi et al., 2010). In our work, we con-

sider that the timestamp is the time when the value

is written.

• Vd (Validity duration): it indicates the amount of

time during which the attribute value is considered

valid. This ﬁeld permits to determine, in associa-

tion with the timestamp, the absolute consistency

constraint of the real-time attribute. A real-time

data is considered absolutely fresh with respect to

time as long as the age of the data value is within

a given interval (Ramamritham et al., 2004). For

instance, the speed value is considered valid if

the current time is earlier than the timestamp of

speed followed by the length of the absolute valid-

ity interval of speed, i.e. {speed.Ti+ speed.Vd >

currentTime}.

• Mde (Maxiumum data error): is used to mem-

orize the absolute maximum data error tolerated

on the attribute value (Idoudi et al., 2010). This

value is the upper bound of the deviation be-

tween the current attribute value in the real-time

database and the reported one. Recently, the

demand for real-time services has increased in

most real-time database based applications where

it is desirable to execute transactions within their

deadlines. They also have to use fresh data in

order to reﬂect the real world state. However, it

seems to be difﬁcult for the transactions to both

meet their real-time constraints and to keep the

database consistent. To support this kind of ap-

plications, the data error concept is introduced in

(Amirijoo et al., 2006) to indicate that data stored

in the real-time database may have some deviation

from its value in the physical world.

• Uo (Update operation): is used to update the value

and timestamp ﬁelds of a real-time attribute. For

example, in the Aircraft real-time object, there is

a real-time method, called updateSpeed(), which

periodically updates the speed real-time attribute.

• Nv (Number of versions): is used to preserve real-

time attribute version history. The multi-version

attributes permits to maintain for every attribute

multiple versions for a data item. This minimizes

data access conﬂicts between real-time transac-

tions and reduces the deadline miss ratio. In order

to respect the real-time database size, the number

of versions of each real-time attribute is limited. It

does not have to exceed a maximum data versions

number.

Note that the ﬁelds N, T,M,V, and Va characterize

classical attributes as well as real-time attributes,

whereas the ﬁelds Ti,Vd,Mde,Uo,and Nv character-

ize only real-time attributes. Here an example of two

attributes in the Aircraft real-time object: the ﬁrst is

a classical attribute and the second is a real-time at-

tribute.

{N = destination, T = string,M = 1,V =

private,Va = Paris}

{N = speed,T = real,M = 1,V = private,Va =

600, Ti = 01/05/2012 10 : 05 : 23,Vd = 30s,Mde =

10,Uo = updateSpeed(),Nv = 5}

Real-time data are classiﬁed into either sensor or

derived data (Ramamritham et al., 2004). Thereby,

F-RTOO data model deﬁnes two kinds of real-time

attributes: sensor attribute and derived attribute. A

sensor attribute is used to store a sensor data which is

periodically updated in order to reﬂect the real world

state of the environment. A derived attribute is used

to store a derived data which is sporadically updated

ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems

268

when a sensor attribute value, used in its computa-

tion, changes. In DL assertions a sensor and derived

attribute are stated as follow:

∀x.RTA(x) ⊆ Sensor(x) ⊔ Derived(x)

∀x.Sensor(x) ⊆ RTA(x)

∀x.Derived(x) ⊆ RTA(x)

4.2 Real-time Operation

The only way that objects can be accessed by trans-

actions is to invoke the operations deﬁned by objects.

In F-RTOO data model, each operation execution is

considered as a real-time transaction. A real-time op-

eration can be stated by means of DL such:

∀x,y,RTO(x) ⊆ ∀n(x).string(y)

∀x,y,RTO(x) ⊆ ∀v(x).string(y)

∀x,y,RTO(x) ⊆ ∀arg(x).string(y)

∀x,y,RTO(x) ⊆ ∀exc(x).string(y)

∀x,y,RTO(x) ⊆ ∀op(x).string(y)

∀x,y,RTO(x) ⊆ ∀mc(x).string(y)

∀x,y,RTO(x) ⊆ ∀mst(x).dateTime(y)

∀x,y,RTO(x) ⊆ ∀mrd(x).duration(y)

∀x,y,RTO(x) ⊆ ∀oct(x).dateTime(y)

∀x,y,RTO(x) ⊆ ∀rt(x).string(y)

∀x,y,RTO(x) ⊆ ∀per(x).duration(y)

∀x,y,RTO(x) ⊆ ∀pri(x).integer(y)

∀x,y,RTO(x) ⊆ ∀cp(x).concurrencyKind(y)

• N (Name): denotes the name of the real-time

method.

• V (Visibility): indicates whether a real-time

method is public, protected, or private.

• Arg (Arguments): is a set of arguments for the

real-time method, where each argument has the

same structure as an attribute, and is used to pass

information in the method.

• Exc (Exceptions): is a set of exceptions that may

be raised by the real-time method to signal that

the method has terminated abnormally.

• Op (Operations): is a set of operations which rep-

resent the impementation of the method.

• Mc (Method constraints): is a set of methods

constraints. A method constraint is of the form

< N, OpSet,Pred,Er > where N is the name of

the method constraint, OpSet represents a subset

of the operations in Op, Pred is a boolean expres-

sion which is speciﬁed over OpSet to express ex-

ecution constraints, timing constraint and prece-

dence constraints, and Er is a enforcement rule.

The enforcement rules are used to specify the ac-

tions to take if the predicate (i.e. Pred) evaluates

to false. A complete deﬁnition of an enforcement

rule is described in the next subsection on con-

straints. Here is an example of a method con-

straint predicate in the Aircraft real-time object:

Pred : getLane().Mct < currentTime+ 5s

A deadline of currentTime +5s has been speciﬁed

for the completion of the getLane() method. Note

the use of the Mct property which represents the

completion time of the executable method.

• Mst (Method start time): indicates the execution

start time of the real-time method.

• Mrd (Method relative deadline): speciﬁes the

deadline of a method execution.

• Mct (Method completion time): indicates the time

at which the method ﬁnishes its execution.

• Rt (Return type): speciﬁes which kinds of value

or object a real-time method can return.

• Per (Period): indicates the frequency of the real-

time method initiation.

• Pri (Priority): Priority speciﬁes the priority order

of a real-time method.

• Cp (Concurrency policy): speciﬁes the concur-

rency policy of a real-time method. A concur-

rency policy may be reader, writer or parallel

(Louati et al., 2011). A reader real-time method

implies that multiple calls from concurrent meth-

ods may occur simultaneously and will be exe-

cuted simultaneously if there is no writer meth-

ods using one or more data that the reader method

needs. A writer real-time method implies that

multiple calls from concurrent methods may oc-

cur simultaneously and will be treated as soon as

concurrency on data permits its execution. A par-

allel real-time method is a method whose actions

do not use any data of the database in reading

mode nor in writing mode.

Real-time transactions are classiﬁed into three cat-

egories: periodic transactions, aperiodic transac-

tions and sporadic transactions (Ramamritham et al.,

2004). Thereby, F-RTOO data model speciﬁes three

types of operations: periodic operations, aperiodic

operations, and sporadic operations. Periodic opera-

tions update periodically sensor data. They are write-

only operations that obtain the state of the real world

and write the sensed data to the database. Sporadic

operations calculate sporadically derived data. The

access mode of the sporadic operation to derived data

is always write. Aperiodic operations do not write any

real-time data, but they can read/write non real-time

Object-orientedReal-timeDatabaseDesignbasedonDescriptionLogics

269

data and only read real-time data. In DL assertions

periodic, aperiodic and sporadic real-time operations

are stated as follow:

∀x.RTO(x) ⊆ Periodic(x) ⊔ Aperiodic(x)

⊔ Sporadic(x)

∀x.Periodic(x) ⊆ RTO(x)

∀x.Aperiodic(x) ⊆ RTO(x)

∀x.Sporadic(x) ⊆ RTO(x)

4.3 Real-time Class

The design of a real-time database, which is by

deﬁnition a database system, has to take into ac-

count the management of many components such

as queries, schemas, transactions, commit protocols,

concurrency control protocol, and storage manage-

ment (Stankovic et al., 1999). In order to deal with

time-constrained data, time-constrained operations,

parallelism, and concurrency property inherent to

real-time databases, we introduce the real-time class

concept. This latter speciﬁes that instances of a class

will encapsulate real-time attributes and real-time op-

erations and a local concurrencymechanism. Because

of the dynamic nature of the real world, more than

one operations may send requests to the same real-

time class. Concurrent execution of these operations

allows several methods to run concurrently within the

same class. To handle this essential property of real-

time database systems, we associate to each real-time

class a local concurrency control mechanism, that

manages the concurrent execution of its operations.

Thus, the class receives messages (or requests) awak-

ing its local controller that checks the timing con-

straint attached to messages and selects one message

following a special scheduling algorithm. 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 an operation terminates its execution,

the corresponding thread is released and concurrency

constraints are relaxed (Louati et al., 2011).

The following DL assertions state that a real-time

class is composed of: a set of real-time attributes, a

set of real-time operations, and a local controller.

∀x.LC(x) ∈ RTC(x) ⊔ ∀x.¬RTC(x) ∈ LC(x)

∀x.RTA(x) ∈ RTC(x) ⊔ ∀x.¬RTC(x) ∈ RTA(x)

∀x.RTO(x) ∈ RTC(x) ⊔ ∀x.¬RTC(x) ∈ RTO(x)

5 A CASE STUDY

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

Figure 2: Freeway Trafﬁc Control System Class Diagram.

ample to prove relevance of our propositions. We il-

lustrate our proposal on a freeway trafﬁc control sys-

tem. As depicted in the Figure 2, the freeway trafﬁc

control system architecture consists of three entities

respectively dedicated to: represent a transport infras-

tructure road that links two conurbations (RoadLink),

depict a part of a route (RoadSegment), and repre-

sent physical entity (Vehicle). RoadSegment and Vehi-

cle represent the description of two physical elements

that are supervised by the controller. In addition, they

are characterized by one or more real-time data which

could determine theirs evolution. These real-time data

are classiﬁed into either sensor data or derived data.

In fact, each vehicle has two sensor data (i.e. speed

and length) which are periodically updated to reﬂect

its state and each road segment has two derived data

(i.e. trafﬁcVolume, and trafﬁcOccupancy) which are

calculated from sensor data.

Deﬁnition of properties of RoadLink’s class cap-

ture attributes and operations as follows:

∀x,y.RoadLink(x) ⊆ ∀linkNum(x).integer)

∀x,y.RoadLink(x) ⊆ ∀P

getLinkNum()

.integer(y)

⊓ (6 1 P

getLinkNum()

)

The same manner deﬁnes attributes and operations for

each other classes (i.e. Vehicle and RoadSegment).

∀x,y.Vehicle(x) ⊆ ∀vehicleNum(x).integer(y)

∀x,y.Vehicle(x) ⊆ ∀speed(x).real(y)

∀x,y.Vehicle(x) ⊆ ∀length(x).real(y)

∀x,y.Vehicle(x) ⊆ ∀P

getSpeed()

.real(y)

⊓ (6 1 P

getSpeed()

)

∀x.Vehicle(x) ⊆ ∀P

updateSpeed()

⊓ (6 1 P

updateSpeed()

)

∀x,y.Vehicle(x) ⊆ ∀P

getLength()

.real(y)

⊓ (6 1 P

getLength()

)

ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems

270

∀x.Vehicle(x) ⊆ ∀P

updateLength()

⊓ (6 1 P

updateLength()

)

∀x,y.Vehicle(x) ⊆ ∀P

getVehicleNum()

.integer(y)

⊓ (6 1 P

getVehicleNum()

∀x,y.RoadSegment(x) ⊆ ∀startPointLocation(x).

integer(y)

∀x,y.RoadSegment(x) ⊆ ∀endPointLocation(x).

integer(y)

∀x,y.RoadSegment(x) ⊆ ∀segmentState(x).string(y)

∀x,y.RoadSegment(x) ⊆ ∀traf ficVolume(x).real(y)

∀x,y.RoadSegment(x) ⊆ ∀traf ficOccupancy(x).

real(y)

∀x,y.RoadSegment(x) ⊆ ∀P

getSegState()

.string(y)

⊓ (6 1 P

getSegState()

)

∀x.RoadSegment(x) ⊆ ∀P

computeTra fVol()

⊓ (6 1 P

computeTra fVol()

)

∀x,y.RoadSegment(x) ⊆ ∀P

getTrafVol()

.string(y)

⊓ (6 1 P

getTrafVol()

)

∀x.RoadSegment(x) ⊆ ∀P

computeTra fOccu()

⊓ (6 1 P

computeTra fOcc()

)

∀x,y.RoadSegment(x) ⊆ ∀P

getTrafOccu()

.string(y)

⊓ (6 1 P

getTrafOccu()

)

6 CONCLUSIONS

This paper has shown the formalization of a real-time

object-oriented data model in term of speciﬁed logic

i.e Description Logics. Through this formalization,

the deductive capabilities of DL have been exploited.

Moreover, the proposed data model not only capture

the structural aspects of a real-time database features,

but also the behavioral aspects. Additionally, it pro-

vides designers a data model where they can specify

both temporal aspects of data and timing constraints

on transactions as well as concurrency control mech-

anism.

We are currently working on the implementation

of a real-time query language that supports our real-

time object-oriented data model.

REFERENCES

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.

Baader, F., Calvanese, D., McGuinness, D. L., Nardi, D.,

and Patel-Schneider, P. F., editors (2003). The De-

scription Logic Handbook: Theory, Implementation,

and Applications. Cambridge University Press.

Efrizoni, L., Wan-Kadir, W., and Mohamad, R. (2010). For-

malization of uml class diagram using description log-

ics. In Information Technology (ITSim), 2010 Interna-

tional Symposium in, volume 3, pages 1168–1173.

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.

Lee, J., Son, S. H., and Lee, M.-J. (1994). Issues in develop-

ing Object-Oriented Database Systems for Real-Time

Applications. In Proceeding of the IEEE Workshop on

Real-Time Applications, volume 26, pages 136–140,

Washington, DC, USA. IEEE Computer Society.

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

(2011). RTO-RTDB: A real-time object-oriented

database model. In In Proceedings of the Interna-

tional Conference on Parallel and Distributed Com-

puting and Systems. ACTA Press.

Perkusich, M. L., de Fatima, M., Turnell, Q., and Perkusich,

A. (1995). Object-oriented real-time database design

based on petri nets. In In Proceedings of the Interna-

tional Workshop on Active and Real-Time Database

Systems, pages 104–121. Springer.

Prichard, J., DiPippo, L., Packham, J., and Fay-Wolfe, V.

(1994). RTSORAC: A Real-Time Object-Oriented

Database Model. In Springer-Verlag, editor, Proc.

of the 5

Intl. Conf. on Database and Expert Sys-

tems Applications (DEXA’94), pages 601–610, Lon-

don, UK.

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

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

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. and Son, S. H. (1998). Architecture and

object model for distributed object-oriented real-time

databases. In ISORC, pages 414–424.

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

conceptions about real-time databases. IEEE Com-

puter, 32(6):29–36.

Taina, J. and Raatikainen, K. (1997). Rodain: a real-

time object-oriented database system for telecommu-

nications. In Proceedings of the workshop on on

Databases: active and real-time, CIKM ’96, pages

10–14, New York, NY, USA. ACM.

Object-orientedReal-timeDatabaseDesignbasedonDescriptionLogics

271