A DECLARATIVE EXECUTABLE MODEL FOR OBJECT-BASED

SYSTEMS BASED ON FUNCTIONAL DECOMPOSITION

Pierre Kelsen

Laboratory for Advanced Software Systems

University of Luxembourg

Keywords:

Declarative models, executable, object-oriented programming, functional programming, software complexity,

functional decomposition.

Abstract:

Declarative models are a commonly used approach to deal with software complexity: by abstracting away

the intricacies of the implementation these models are often easier to understand than the underlying code.

Popular modeling languages such as UML can however become complex to use when modeling systems in

sufﬁcient detail.

In this paper we introduce a new declarative model, the EP-model, named after the basic entities it contains -

events and properties - that possesses the following features: it has a small metamodel; it supports a graphical

notation; it can represent both static and dynamic aspects of an application; ﬁnally, it allows executable models

to be described by annotating model elements with code snippets. By leaving complex parts at the code level

this hybrid approach achieves executability while keeping the basic modeling language simple.

1 INTRODUCTION

Abstraction is a key concept for dealing with com-

plexity. By abstracting away details of the implemen-

tation one can construct a higher-level model that is

easier to understand than the underlying code. Al-

though the relations between successive abstraction

layers are varied, a common theme is that of separat-

ing what a system does from how it is actually done.

We call the approaches that rely on this distinction

declarative.

An important element of a declarative approach

is the language used for representing the high-level

models. The de-facto standard for modeling object-

oriented systems is the Uniﬁed Modeling Language

(Object Management Group, 2003). The UML is a

powerful language for describing systems at various

levels of abstraction and from multiple viewpoints. It

has a large number of diagrams available for describ-

ing systems from different perspectives, each with

their own syntax and semantics. This expressiveness

also means that UML is a rather large and complex

language (Kobryn, 2002; Siau and Cao, 2001).

The complexity and size of the language becomes a

hindrance when designing systems at a detailed level.

While it is possible in principle to transform UML

into an executable language (Raistrick et al., 2000) by

instrumenting it with a precise Action Semantics (Al-

catel et al., 2000) this results in an even bigger lan-

guage. Indeed executability and simplicity seem to

be conﬂicting goals if we judge by previous attempts.

The main subject of this paper is a new executable

model, the EP-model, that is based on a rather trivial

observation: certain aspects of programs can be eas-

ily presented in a simple form at a declarative level

while other aspects are much more difﬁcult to capture

at such a level. Our basic approach to this problem

is that of leaving things that are truly complex to de-

scribe at a low level (source code) and extracting only

those aspects that can easily be presented.

We now discuss the main features of EP-models

and contrast them with existing approaches. The sim-

plicity of EP-models is mainly due to the small num-

ber of concepts that they are based on: indeed the

high-level metamodel can be described using only

two types of entities - events and properties - and four

types of relationships among those entities.

The second main feature of EP-models is their ex-

ecutability. Executability by itself is not a new idea

(e.g., (Belina and Hogrefe, 1989; Raistrick et al.,

2000)). What makes our model interesting is the fact

that executability is achieved without relying on a

Kelsen P. (2006).

A DECLARATIVE EXECUTABLE MODEL FOR OBJECT-BASED SYSTEMS BASED ON FUNCTIONAL DECOMPOSITION.

In Proceedings of the First International Conference on Software and Data Technologies, pages 63-68

DOI: 10.5220/0001317300630068

 SciTePress

overly complex language for the modeling notation.

Instead we propose a hybrid approach in which the

model itself is unchanged but code segments annotate

the various modeling elements to allow executabil-

ity. A useful characteristic of our hybrid approach

is the ”locality” of the code segments: indeed each

code snippet can only refer to the model elements that

are adjacent to the element that it annotates. Clearly

this locality reduces coupling since it disallows the

code to access elements that it is not related to. Al-

though there have been a few approaches to reduce

coupling at the method level (the Law of Demeter

(Lieberherr and Holland, 1989) is representative of

such approaches) current approaches are rather low-

level in the sense that they refer to an existing class

structure. On the other hand the EP-models provide

a ”sandboxing” approach for code that is situated at a

higher semantic level.

Finally, EP-models model both static and dynamic

aspects of a system in a single diagram. On the other

hand UML separates static and dynamic aspects into

different diagrams. One reason for this difference

lies in the fact that while UML is largely grounded

in the object-oriented paradigm our model combines

ideas from both object-oriented and functional pro-

gramming: it borrows the notion of state from object-

oriented programming while representing dynamic

behavior as functions without side-effects that are

decomposed over the state. We remark that the

idea of combining the functional and object-oriented

paradigms is not new but most attempts have focused

so far at the level of programming language design

(e.g., (Hughes and Sparud, 1995; R

emy and Vouillon,

1997; Odersky and Wadler, 1997)).

2 AN EXAMPLE: FLASHCARDS

To illustrate the concepts introduced in this paper, we

will make use of a simple application called Flash-

Cards that will be used as a running example. The ap-

plication allows the user to design and work with a set

of ﬂash cards. A ﬂash card contains of a question and

an answer. Flash cards are commonly used as a study

aid. The application should allow the user to add a

number of ﬂash cards, specifying for each card the

corresponding question-answer pair. The main win-

dow should present an overview of the cards entered

so far. The user can enter a special quiz mode: in this

mode he can review the ﬂash cards one at a time. For

each ﬂash card the question is displayed and the user

can choose to also view the answer.

3 THE STATIC VIEW: LOCAL

PROPERTIES AND THE

SYSTEM STATE

The static structure of an EP-system is given by a set

of local properties in each model. (A second class

of properties named query properties will be intro-

duced in section 6). Local properties have a name and

a type. We shall assume that no two properties in

the same model have the same name. The type has a

name and an associated set of values. This type can be

either internal or external: an internal type is given

by another model in the EP-system. Examples of ex-

ternal types are the built-in types of a programming

language or a class in a class library; external types

are not represented by EP-models. A property is ei-

ther single-valued or multi-valued. We call multival-

ued properties also collection properties.

Example 1 We name the EP-model for represent-

ing a ﬂash card FlashCard. This model contains

two properties, named question and answer, of type

java.lang.String, an external Java type. Another ex-

ample is the Main EP-model representing the main

window of the FlashCards application. The addBut-

ton and quizButton properties are properties of an ex-

ternal type (SWING components). The other proper-

ties of the Main model - list, cardDialog, quizDialog,

ﬂashCards - have an internal type represented by an

EP-model. We note that the ﬂashCards property is a

collection property of type FlashCard - this property

refers to the collection of ﬂash cards entered by the

user.

When an EP-model executes, it goes through a series

of system states. Informally, a system state is a set

of instances, each instance belonging to some model

and assigning concrete values to the local properties

in that model.

For a more formal deﬁnition of a system state:

Deﬁnition 1 A valuation for a model M is a function

that assigns to each local property p in M a value of

the type of p.

Deﬁnition 2 An instance of model M is a triplet

(M, id, φ) where M is a model, id is a name for the

instance and φ is a valuation for M . We call φ(p) is

the value of (local) property p in M on this instance.

Deﬁnition 3 A system state is a set of instances.

Condition In any system state the id’s of the in-

stances are unique.

ICSOFT 2006 - INTERNATIONAL CONFERENCE ON SOFTWARE AND DATA TECHNOLOGIES

4 EVENTS, THE

TRANSFORMATION MAPPING

AND CENTERED FUNCTIONS

External triggers that modify the current system state

are represented in a model by local events. (Another

class of events - remote events - will be presented in

a later section.) A local event has a name, a type and

a source. We shall assume that no two events in the

same model have the same name.

The event type is platform-speciﬁc: in Java an

event type is a pair (l, m) where l is a listener inter-

face and m a method of this interface.

The source of an event is a local property in the

model that contains the event.

Example 2 In the Main model we have two lo-

cal events add and quiz. The add event repre-

sents pressing the add button and the quiz event oc-

curs when we press the quiz button. Both events

have as type (java.awt.event.ActionListener, action-

Performed). The source of the add event is the ad-

dButton property of the Main model and the source of

the quiz event is the quizButton property of the quiz

event.

Deﬁnition 4 We say that a local event occurs on an

instance x if an (external) event of the given type oc-

curs on the object referred to by the source of the local

event. In this case we also say that instance x is the

locus of the local event.

Example 3 When we press the add button in the main

window, an event occurs on the Main instance; this

instance is then the locus of this event.

Deﬁnition 5 When a local event occurs on instance

x of the current system state, then the current state is

replaced by a new state which we call the result state.

Deﬁnition 6 For a given local event e the mapping

that associates with each system state and instance of

this state on which e occurs a result state is called the

transformation mapping for e and is denoted by F

Mathematically we describe transformation map-

pings using centered functions.

Deﬁnition 7 A centered state is a pair (s, x) where s

is a system state and x is an instance of s. We call x

the center of the centered state.

Notation We also use s(x) to denote a system state s

centered at x.

Deﬁnition 8 A centered function is a function whose

domain is a set of centered states (for the given EP-

system).

We may view the transformation mapping F

as a

centered function that maps the current state centered

at the locus of the event to the result state.

The transformation mapping completely describes

the dynamic behavior of an EP-system. Indeed if the

EP-system expresses the transformation mapping pre-

cisely, then the EP-system is executable. The remain-

der of this paper is essentially looking at the question

of how to best represent centered function F

at the

level of the EP-models.

5 BICENTERED FUNCTIONS

To represent the transformation mapping, we shall de-

compose it into simpler functions. First we need to

deﬁne the effect an event has on a system state.

Deﬁnition 9 A local event e affects a local property

p if for some system state the value of this property is

changed on some instance of this state when the event

occurs. In this case we also say that the local event

affects property p on this instance.

Example 4 The effect of the quiz event in the Main

model is to show the QuizDialog, to set the question-

Field (a text ﬁeld) to the ﬁrst question and to set the

index property indicating the position of the current

card among the stack of ﬂash cards. Thus the quiz

event affects the visible and index properties of Quiz-

Dialog.

To fully describe a local event e, it sufﬁces to spec-

ify the effect of e on each local property affected by

e. The effect of e on property p can be expressed by

the function that returns the new value of property p

on an instance of the result state after e occurs on the

current state; we denote this function by F

e,p

Example 5 Let e denote the quiz event in the Main

model and let p stand for the visible property in

the QuizDialog model. Then F

represents the new

value of the visible property when the quiz event oc-

curs; in this case F

e,p

= tr ue.

The value of F

e,p

depends on two centered states:

• the current state s(x) centered at the locus of local

event e, i.e., at the instance where e occurs

• the result state centered at an instance at which we

are evaluating the new value of p

This dual dependency motivates the next deﬁnition.

Deﬁnition 10 A bicentered function is a function of

the form f(s(x), s

′

(y)) where s(x) and s

′

(y) are two

system states centered at instances x and y, respec-

tively.

We note that function F

e,p

is a special bicentered

function where the second argument state is the result

state.

The centered function F

is fully speciﬁed by the

functions F

e,p

, where p ranges over all properties af-

fected by e. We have thus reduced the problem of de-

composing the centered transformation mapping F

A DECLARATIVE EXECUTABLE MODEL FOR OBJECT-BASED SYSTEMS BASED ON FUNCTIONAL

DECOMPOSITION

into that of decomposing the related bicentered func-

tions F

e,p

. Before we address the decomposition of

bicentered functions, we explain how to decompose

centered functions since they will be used in the de-

composition of the bicentered functions.

6 DECOMPOSING CENTERED

FUNCTIONS USING

PROPERTY GRAPHS

In this section we shall describe how to decompose

centered functions and how to represent this decom-

position in EP-models.

The computation of a centered function will be

based on the decomposition of this function into “sim-

pler” functions. Each centered function is represented

at the model level by a query property. Just like

local properties query properties have a name and a

type. Local properties and query properties together

make up the set of properties of an EP-system. To de-

compose the query property, we ﬁrst describe which

values a query property depends on. This is done by

deﬁning for each query property a property graph.

Deﬁnition 11 The property graph for a query prop-

erty q is deﬁned as follows: the set of nodes is a set of

properties that contains property q and other local or

query properties. There are three types of edges: lo-

cal edges, forward edges and inverse edges. A local

edge is given by a pair (p

, p

) of properties in the

same model. Forward edges and inverse edges are la-

beled by a property p which we call the link property;

for forward properties the link property is a property

in the model of p

whose type is a model containing p

while for inverse properties the link property belongs

to the model of p

and its type is a model containing

. The link property is a local property or a query

property.

Intuitively, a local edge represents a dependency of

two properties on the same instance while forward

and inverse edges represent a dependency between

two properties on two separate instances connected

by the link property p.

At the model level we represent the property

graph by adding a parent relationship link from a

query property to each of its children properties.

The parent relationship has two attributes: the link

property (undeﬁned for local edges) and type (lo-

cal/forward/inverse).

Example 6 Figure 1 shows the property graph for the

query property nextIndex in the QuizDialog model:

this query property computes the index of the next

card to be displayed in the quiz dialog. The prop-

erty graph contains two local edges and one inverse

Figure 1: Property graph for nextIndex.

edge (having link property quizDialog). The ﬂash-

Cards and index properties are local properties.

We add a code snippet to each query property that

computes the value of the query property in terms of

the values of children properties.

Example 7 The code snippet that computes the value

of property nextIndex is given below. Note that

it only uses values of properties that are chil-

dren of itself in the event graph (see ﬁgure 1).

if (index<cards.size()-1)

result = index+1;

else

result = 0;

7 DECOMPOSING BICENTERED

FUNCTIONS USING EVENT

GRAPHS

To decompose the F

e,p

functions, we will need to pre-

cisely deﬁne what instances in the result state are af-

fected by an event. This will be done by associating

with each local event an event graph.

To deﬁne the event graph for a local event, we ﬁrst

add to each model a set of remote events. Remote

events have a name but unlike local events they do

not have a type and source attribute. Local events and

remote events together make up the set of events of

an EP-system. We may think of remote events as the

representatives of a local event in other EP-models.

Deﬁnition 12 The nodes of the event graph of a lo-

cal event comprise the local event as well as a set of

remote events. The edges of the event graph are ei-

ther forward,inverse or local edges. A forward edge

, e

) is labeled by a property p in the model of e

;

must be an event in the model that is the type of p.

The forward edge is denoted by e

→

. An inverse

edge (e

, e

) is labeled by a property p in the model

of e

; e

must belong to the model that is the type of

p. The inverse edge is denoted by e

֒→

. A local

edge (e

, e

) connects two events in the same model

and does not carry a label; it is denoted by e

→ e

For foward and inverse edges we call property p the

link property. The link property is a local property or

a query property. We call the edges in the event graph

also event links.

ICSOFT 2006 - INTERNATIONAL CONFERENCE ON SOFTWARE AND DATA TECHNOLOGIES

Figure 2: Event tree of the quiz event.

Notation We denote the event graph for a local event

e by G

At the level of EP-models we represent event links us-

ing a parent relationship between events: each parent

link connects a source event to a target event; it has

as attributes a property (the link property, undeﬁned

for local links) and a type attribute (with values: for-

ward/inverse/local).

Example 8 Figure 2 shows the event graph of the

quiz event in the Main model. All events but the quiz

event are remote. All event links are forward links.

Three models are involved: Main, QuizDialog and

EOPTextField, the latter model representing a text

ﬁeld. This reﬂects the fact that the quiz event affects

properties in the QuizDialog instance but also sets the

contents of the question and answer text ﬁelds which

are modeled by EOPTextField.

To decompose the functions F

e,p

over the event graph,

we deﬁne auxiliary functions on the nodes of the event

graph. These functions compute and transmit the in-

formation required by the F

e,p

function.

Deﬁnition 13 A parametrization of an event graph

is given by

- attaching to each event of G

a set of centered

functions represented by query properties

- assigning to each remote event of G

a set of pa-

rameters, where each parameter has a name and a

type

- assigning to each event link l and to each pa-

rameter g in the target event of l a function F

g,l

that expresses the parameter g in terms of param-

eters and centered functions f

at the source of l:

g = F

g,l

, . . . , f

We now describe how the parametrization is repre-

sented at the model level. We may view a local prop-

erty as a very simple centered function that returns

the value at the center of its argument state. We rep-

resent more general centered functions in EP-models

by query properties (see previous section).

We represent the attachment of a centered function

to an event by introducing a feeds relation from the

query property to the event. Each non-local event in

an EP-model has a set of parameters. The function

g,l

is represented by attaching a code snippet for pa-

rameter g to the event link from the source to the tar-

get event.

We have now all the pieces together for implement-

ing a local event e at the level of an EP-system: de-

compose the transformation mapping F

into the bi-

centered functions F

e,p

, one for each property p af-

fected by e. For each function F

e,p

create an event

graph with a parametrization that provides a func-

tional decomposition of F

e,p

. Note that this may

entail creating new query properties feeding remote

events. Finally decompose these query properties us-

ing property graphs. Repeating these steps for each

local event will result in an executable EP-system that

represents the ﬁnal application. For a more detailed

description and additional examples the reader is re-

ferred to (Kelsen, 2006).

8 APPLICATIONS OF

EP-SYSTEMS

We see three directions for future work that corre-

spond to potential applications of EP-models.

1. Modeling applications: as we have seen in this pa-

per we can use EP-models to model simple appli-

cations. Because EP-models are executable the EP-

system in fact constitutes the application: no addi-

tional code is needed. Of course in practice one

would write a code generator for efﬁcient execu-

tion. To prove the feasibility of this approach we

have developed a tool (Glodt and Kelsen, 2006)

that provides a visual environment for designing

EP-systems: the tool is implemented as an Eclipse

plug-in that supports editing and executing EP-

models with rule-based background code genera-

tion. It is not clear yet whether EP-models are

a reasonable approach for modeling large applica-

tions: to answer this question, we are planning to

develop such an application using our tool. In any

case EP-models would supplement rather than re-

place existing UML models: indeed many UML ar-

tifacts such as use cases and deployment diagrams

could supplement EP-models by providing high-

level views of the application and also describing

aspects not represented by our models.

2. Mastering software complexity: EP-models have

a number of features that may help in controlling

the complexity of the resulting system: ﬁrst EP-

systems exhibit locality because code snippets may

only depend on values that are located on ”adja-

cent” elements in the EP-system. We have imple-

mented (Glodt and Kelsen, 2006) this locality us-

ing a sandbox model: the sandbox for a code snip-

pet only contains the values that are accessible by

this code in the model. This locality should help

in reducing coupling ((Stevens et al., 1999)) in the

resulting application. Second the models provide

A DECLARATIVE EXECUTABLE MODEL FOR OBJECT-BASED SYSTEMS BASED ON FUNCTIONAL

DECOMPOSITION

facilities for comnprehending the dynamic behav-

ior of an EP-system: we can understand the effect

of an event on the system by following the edges of

the event tree. Similarly data dependencies can be

quickly discovered with the help of property trees.

3. A laboratory for testing object-oriented methods

and concepts: since our models provide a restricted

environment for describing the static and dynamic

aspects of an application, they should be easier to

analyze and can be used as a testbed for devel-

oping mathematical models that may carry over

to more unrestricted environments. For example

techniques such as design patterns (Gamma et al.,

1995) or refactoring (Fowler, 1999) could be ex-

amined in these more restricted models. This could

potentially provide a more rigorous basis for these

techniques that could carry over at least in part to

more traditional software programs. Another ben-

eﬁt of trying out these techniques on EP-models is

of course their potential to make the EP-modeling

process more effective.

9 CONCLUSIONS

We have presented a declarative model, named the

EP-model. EP-models are based on a small meta-

model comprising two types of entities, events and

properties, and four binary relationships between

those entities.

EP-models are executable; executability is

achieved by associating code snippets with entities

and relationships. These code snippets compute

functions without side-effects. This hybrid approach

allows one to keep the basic modeling language

simple by leaving complex parts at the code level.

The code snippets obey a locality constraint: they

can only use values connected with neighboring

modeling elements. This reduces the amount of

coupling in the resulting application.

EP-models combine static and dynamic aspects of a

system in a single diagram. They combine the notion

of state from object-oriented programming with the

notion of functional decomposition from functional

programming.

Future work will examine

• whether EP-models can be used to model appli-

cations of a realistic size and what the advan-

tages/disadvantages are over existing UML-based

methods;

• whether EP-models can be used as a cleanroom for

testing object-oriented ideas and concepts. As an

example we plan to study refactoring and design

patterns in the context of these models. Because of

the simple structure and executability of these mod-

els, such a study could provide a more rigorous ba-

sis for some of these techniques which could then

possibly be carried over to more traditional soft-

ware programs.

REFERENCES

Alcatel, I-Logix, Kennedy-Carter, Technologies, I. K.,

Technology, I. P., Corporation, R. S., and AB., T.

(2000). Action semantics for the UML. In Document

ad/2001-03-01. OMG.

Belina, F. and Hogrefe, D. (1989). The ccitt-speciﬁcation

and description language sdl. Comput. Netw. ISDN

Syst., 16(4):311–341.

Fowler, M. (1999). Refactoring: Improving the Design of

Existing Code. Addison-Wesley. FOW m 01:1 1.Ex.

Gamma, E., Helm, R., Johnson, R., and Vlissides, J.

(1995). Design Patterns : Elements of Reusable

Object-Oriented Software. Addison Wesley.

Glodt, C. and Kelsen, P. (2006). Demos: A tool for declar-

ative executable modeling of object-based systems.

Hughes, J. and Sparud, J. (1995). Haskell++: An Object-

Oriented Extension of Haskell. In Proceedings of

Haskell Workshop, La Jolla, California, YALE Re-

search Report DCS/RR-1075.

Kelsen, P. (2006). A declarative executable model for

object-based systems based on functional decompo-

sition. Technical Report TR-LASSY-06-06, Labora-

tory for Advanced Software Systems, University of

Luxembourg. http://lassy.uni.lu/demos/

documentation/TR_LASSY_06_06.pdf.

Kobryn, C. (2002). Will uml 2.0 be agile or awkward?

Commun. ACM, 45(1):107–110.

Lieberherr, K. and Holland, I. (1989). Assuring a good style

for object-oriented programs. IEEE Software, pages

38–48.

Object Management Group (2003). Uniﬁed modeling lan-

guage, march 2003. version 1.5.

Odersky, M. and Wadler, P. (1997). Pizza into Java: Trans-

lating theory into practice. In Proceedings of the 24th

ACM Symposium on Principles of Programming Lan-

guages (POPL’97), Paris, France, pages 146–159.

ACM Press, New York (NY), USA.

Raistrick, C., Wilkie, I., and Carter, C. (2000). Executable

UML (xUML). In Proceedings 3rd International Con-

ference on the Uniﬁed Modeling Language UML.

emy, D. and Vouillon, J. (1997). Objective ML: A simple

object-oriented extension of ml. In Proceedings of the

24th ACM Conference on Principles of Programming

Languages, pages 40–53, Paris, France.

Siau, K. and Cao, Q. (2001). Uniﬁed modeling language:

A complexity analysis. Journal of Database Manage-

ment, 12(1):26–34.

Stevens, W. P., Myers, G. J., and Constantine, L. L. (1999).

Structured design. IBM Syst. J., 38(2-3):231–256.

ICSOFT 2006 - INTERNATIONAL CONFERENCE ON SOFTWARE AND DATA TECHNOLOGIES