A Case Study of Combining Compositional and Object-oriented

Software Development

Enn Tyugu, Mait Harf and Pavel Grigorenko

Institute of Cybernetics, Tallinn University of Technology, Tallinn, Estonia

Keywords:

Domain-speciﬁc Modeling, Structural Synthesis of Programs, Model Driven Software Development, Compo-

sitional Software Design.

Abstract:

We analyze an approach to software development where object-oriented and compositional software speciﬁ-

cations are written in separate languages and are only loosely connected. It supports compositional design of

software in a domain-speciﬁc language and automatic model-driven construction of code from classes written

in Java. We justify our approach by giving examples of development of large simulation programs and services

on large models. We present also an example of using our method in general purpose software development –

this is bootstrapping the essential part of a software tool CoCoViLa, i.e. synthesizing CoCoViLa in CoCoViLa

itself.

1 INTRODUCTION

Model-driven engineering (MDE) (Kent, 2002; Soft-

ware, 2003), a.k.a. model-driven software engineer-

ing (MDSE) is gaining popularity in software devel-

opment practice. This raises the level of abstraction

of software speciﬁcations and simpliﬁes the devel-

opment of domain-oriented languages (DSL). MDSE

tools use compositional approach to software speciﬁ-

cation. At ﬁrst glance, it seems natural to use classes

as components in MDE. However, in the object-

oriented paradigm, classes are still programming con-

cepts and are too closely related to implementation.

They are rather inconvenient to use immediately as

components. To overcome this inconvenience, one

can deﬁne components differently from classes. An

approach can be to introduce a speciﬁcation language

for specifying models and their components, sepa-

rating the implementation aspects as much as possi-

ble from the domain speciﬁc software speciﬁcations.

This has been done in several visual programming

tools like MetaEdit+ (Tolvanen and Kelly, 2009) and

CoCoViLa (Grigorenko et al., 2005).

The main result presented here are three case stud-

ies justifying the method where object-oriented and

compositional speciﬁcations are combined in soft-

ware development with minimal restrictions on both.

Object-oriented programming is done in Java, but

it could have been C++ or any other OO language.

Compositional speciﬁcation is written in a DSL de-

veloped with a tool brieﬂy introduced ﬁrst in (Grig-

orenko et al., 2005) and developed further during the

following years. It is essential that OO and com-

positional speciﬁcations have separate name spaces,

and can be developed almost independently. The pre-

sented approach is justiﬁed by three applications re-

viewed in the present paper. The ﬁrst two use DSLs in

simulation and service composition. Both solve large

problems that validate the scalability of the approach.

The third is an example of model-based development

of a rather large software tool. More precisely, it is

bootstrapping CoCoViLa in CoCoViLa itself, whose

source code is available from the web

This presentation is organized as follows. We dis-

cuss background and the related work in Section 2.

Section 3 introduces basic concepts and the compo-

sitional speciﬁcation language. The following three

sections are case studies demonstrating scalability

and applicability of the method. The presentation

ends with a brief conclusion part.

2 BACKGROUND AND RELATED

WORK

Model-driven approach to computing has a long his-

tory in speciﬁc domains like integrated circuit design

and many simulation applications. The tools required

http://www.cs.ioc.ee/cocovila

201

Tyugu E., Harf M. and Grigorenko P..

A Case Study of Combining Compositional and Object-oriented Software Development.

DOI: 10.5220/0004698502010208

In Proceedings of the 2nd International Conference on Model-Driven Engineering and Software Development (MODELSWARD-2014), pages 201-208

ISBN: 978-989-758-007-9

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

for these applications are complicated and their devel-

opment has been expensive. For example, todays net-

work simulation tools like OPNET, OMNeT++ and

ns-3 are large software systems and some of them cost

hundreds of thousands of dollars. Experience shows

that developing a new tool of this kind takes years.

A completely new trend was initiated in the

nineties with introduction of UML – a universal

modeling language that has become a standard for

software speciﬁcation, and has inﬂuenced also re-

search in software engineering. One can say that

UML has initiated model-driven software engineer-

ing (MDSE) (Brambilla et al., 2012). Considerable

attempts have been made recently using UML-based

metamodels and model transformations for automat-

ing software development (Santos et al., 2010). Gen-

erally speaking, metamodels and model transforma-

tion rules should be a background knowledge that

support automation of program construction in vari-

ous application domains.

Domain speciﬁc languages (DSL) have initially

been developed independently of model-based ap-

proach to computing. Their history begins early in

the middle of the last century with languages for nu-

meric control of machine tools. Only recently, the

research in DSLs and visual languages has adopted

also model-based approach. The work most closely

related to our research is performed by the Meta-

Case group which has developed MetaEdit+ (Tolva-

nen and Kelly, 2009). This work is based on domain-

speciﬁc modeling (DSM). The technology prescribes

analysis of a domain and development of a DSL

ﬁrst. This language enables one to specify models

that are high-level speciﬁcations of systems and prob-

lems to be solved. The principal step is the develop-

ment of a code generator speciﬁc to the domain. The

book (Kelly and Tolvanen, 2008) presents lots of ex-

amples of both – DSL development and code gener-

ator development. Finally, a library of reusable code

can be added and, as a result, a domain framework is

created that speeds up the software development dra-

matically (up to 500% and 1000% according to (Kelly

and Tolvanen, 2008)).

Our software technology is similar to DSM of the

MetaCase group. However, we use deductive pro-

gram synthesis for code generation. This makes the

implementation of a new DSL much faster, because

no generator development is needed.

The research in deductive program synthesis

has a long history, beginning with the works

of C. Green (Green, 1980), Z. Manna, R.

Waldinger (Manna and Waldinger, 1993) and R. Con-

stable (Constable, 1971). Our work is based on a tool

that uses a special kind of the deductive synthesis –

structural synthesis of programs (SSP) (Matskin and

Tyugu, 2001). SSP is oriented at the efﬁciency. Its

weak expressiveness must be compensated by a spec-

iﬁcation language that hides a large number of axioms

needed in practical applications. As the logic of pro-

gram synthesis is out of scope of our presentation, we

will not discuss it here more.

Eclipse Modeling Project

provides tools for

the model-based development. It includes Eclipse

Modeling Framework (EMF), a modeling and code

generation framework for specifying and managing

(Ecore

) metamodels (written as XML ﬁles) and

building applications from such models, Graphical

Editing Framework, a facility for building interactive

user interfaces, and Graphical Modeling Framework,

bridging EMF and GEF by providing runtime infras-

tructures and generative components for building rich

graphical editors. EMP does not provide automatic

code generation, however there are complementing

frameworks that provide such facilities via templates.

Microsoft has created a Visualization and Model-

ing SDK

(DSL Tools) for deﬁning domain-speciﬁc

languages, building visual designer environments and

implementing code generators in Visual Studio. It

uses UML-like notation for diagrams and stores con-

cept deﬁnitions in XML format. Code generators are

deﬁned using template languages. The framework

does not support n-ary relationships and its graphical

capabilities are quite poor, only supporting variations

of rectangles as shapes of objects.

3 COMBINING

OBJECT-ORIENTED AND

COMPOSITIONAL

ARCHITECTURES

There are some principal difﬁculties in combining

the two paradigms. Object-oriented approach widely

uses encapsulation and hiding, and relies on param-

eter passing. Structural composition uses ports for

binding components, it can provide considerable ﬂex-

ibility, and it is more ﬁtted to represent ontology of

a problem domain. We present CoCoViLa framework

as an example of combining object-oriented and com-

positional architectures. The main design principles

of CoCoViLa are the following:

• Two loosely connected speciﬁcations of soft-

ware product are used – compositional (CA) and

http://www.eclipse.org/modeling

A variant of MOF http://www.omg.org/mof/

http://code.msdn.microsoft.com/vsvmsdk

MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

202

object-oriented (OO); the ﬁrst speciﬁes the logic

and structure of software and the second speciﬁes

implementation of software components.

• OO and CA have separate namespaces.

• OO and CA have common type system.

• Inheritance in CA is consistent with inheritance in

OO.

• Each software component has two parts: a Java

class (this is an OO speciﬁcation) and a composi-

tional speciﬁcation called metainterface. A com-

ponent is called metaclass.

• Implementation of logical formulas that deﬁne

functional dependencies between speciﬁcation

variables is described by methods of a corre-

sponding Java class.

A metainterface has precise logical semantics

given as a set of formulas – axioms with realizations

given by methods speciﬁed in the OO part, and equa-

tions (as well as some other language constructs) writ-

ten in the metainterface. CoCoViLa uses a construc-

tive logic – intuitionistic propositional calculus for

synthesizing a program from a model presented as a

logical theory, therefore all axioms must have realiza-

tions. Components can be deﬁned hierarchically, i.e.

a metainterface of a component may contain compo-

nents whose type is given by metaclasses, i.e. by other

components. A metaclass may consist of a metain-

terface only, e.g. in a case when computations are

speciﬁed by equations. Metainterface is written in a

speciﬁcation language. It is included as a comment

in a Java class whose methods are implementations of

the axioms of the metainterface.

Figure 1 shows three dimensions of software com-

position from metaclasses: compositional speciﬁca-

tion, object-oriented implementation, and common

platform supporting both paradigms. On the com-

positional speciﬁcation level (shown in the horizon-

tal plane), instances of metaclasses (i.e. classes with

metainterfaces) are bound by equalities between their

components. One metainterface (an oval shape) can

wrap one class (a rectangular shape) or several meta-

class instances that can be bound with each other.

Metainterfaces are wrappers that provide ﬂexibility to

classes and contain information about their usability.

We see four metaclasses in Figure 1. Three of them

have implementations as Java classes. The fourth in-

cludes their instances as components and has no own

implementation. This supports the hierarchical de-

scription. In another dimension, conventional object-

oriented inheritance and aggregation are supported as

shown by arrows between the classes in Figure 1. A

new class for performing computations must be syn-

Figure 1: Classes, metaclasses and metainterfaces.

thesized from its speciﬁcation given as a metainter-

face and a goal.

We have used several slightly different versions of

a language for specifying metainterfaces in different

versions of the system. A composition language has

to include at least the following constructs.

1. Speciﬁcations of interface variables

type id, [id, ..]

2. Bindings

var1 = var2

3. Axioms

precondition -> postcondition{impl}

Types in CoCoViLa can be primitive Java types

(int, double, etc), Java classes or metaclasses.

Bindings are used for structural composition, to spec-

ify the equality of interface variables var1 and var2

(these can be components of other interface variables

declared in the speciﬁcation).

Axioms are written in a logical language, the

choice of which depends on the availability of a

prover to be used in the synthesizer. In the existing

version of CoCoViLa we use the logic of intuitionistic

propositional calculus as described in (Matskin and

Tyugu, 2001). Names of interface variables are used

as propositional variables. Derivability of a propo-

sitional variable means computability of the respec-

tive interface variable. The preconditions of axioms

can be conjunctions of propositional variables and im-

plications of conjunctions of propositional variables.

The postconditions are conjunctions of propositional

variables. An implication in a precondition denotes a

new goal – a new computational problem whose al-

gorithm has to be synthesized before the method with

this precondition can be applied.

Program synthesis plays an essential role in ap-

plying this logic. However, we only refer to the syn-

thesis method SSP and do not explain it in any detail

here. This is because the method, called also proposi-

ACaseStudyofCombiningCompositionalandObject-orientedSoftwareDevelopment

203

tional logic programing, has been described in a num-

ber of papers already long ago (Matskin and Tyugu,

2001; Mints and Tyugu, 1990), and has been success-

fully used in software development, in particular, in

PRIZ (Mints and Tyugu, 1990) and other similar sys-

tems.

The speciﬁcation language includes also equa-

tions and more means for binding components, but

these features can be modeled in the core of the lan-

guage that is presented here. The following example

is a metaclass of a complex number, where possible

computations are described by equations and no Java

methods are needed except the sin function imported

from java.util.Math and used in an equation.

import java.util.Math;

class Complex {

/*@ specification Complex {

double re, im, arg, mod;

modˆ2 = reˆ2 + imˆ2;

mod * sin(arg) = im;

}@*/

}

4 MODEL-BASED

DEVELOPMENT OF

SIMULATION LANGUAGES

CoCoViLa includes a graphical interface that facil-

itates developing and using visual domain-oriented

languages. This is especially suited for solving of

simulation problems.

Here we present an example of modeling and

simulation of complex ﬂuid power systems (Grosss-

chmidt and Harf, 2009). At the current state, the

language includes about 100 problem-oriented con-

cepts, each represented by a component. These con-

cepts are either simple elements as hydraulic resis-

tors, tubes, connecting hydraulic elements, or hy-

draulic subsystems like regulators, servo-drive with

feedback, electro-hydraulic servo-valve. There are

three levels of hierarchy of hydraulic components and

subsystems.

Figure 2 shows a part of a model for simulation of

dynamic behavior of a hydraulic servo-system. Each

component has a menu button in the scrollable menu

bar. The model includes 48 objects (only 16 objects

are visible in the ﬁgure). However, the objects of

this model are themselves speciﬁed by models, hence

the total number of interface variables involved in the

program synthesis is several thousands. The model is,

in essence, a system of ordinary differential equations

of order 28. Automatically synthesized Java code for

solving this problem contains 8920 lines. The simula-

Figure 2: Part of a model of dynamic behavior of a hy-

draulic servo-system.

Figure 3: Simulation results of step disturbance of load

force.

tion gives behavior of the system under different dis-

turbances. Results of some simulations are presented

in Figure 3. The synthesis takes about one second and

the simulation time on a PC for this example with a

million iterations is three minutes. The graphs show

movement of an actuator and a ﬂapper under a step

disturbance of the load force. One can see that this is

a stiff dynamic system, hence a large number of simu-

lation steps is needed for detecting oscillations of both

low and high frequencies.

5 COMPOSITION OF SERVICES

ON LARGE SERVICE MODELS

As has been shown in (Matskin et al., 2007), the logic

of CoCoViLa is well suited for describing web ser-

MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

204

vices and workﬂows. This inspired us to make exper-

iments with synthesis of public services for Estonian

authorities providing services over Internet. The ﬁrst

attempt was made by collecting all available services

into a single metaclass in CoCoViLa that was called a

service model (Maigre et al., 2009). This resulted in

a large model containing more than 600 atomic ser-

vices developed by different ministries. In order to

achieve compatibility of services, a large number of

data transformers were needed, e.g. transformation of

date or address from one format into another. This

model was used for synthesis of compound services

including data from different authorities. We discov-

ered that it was almost impossible to keep this single

model up-to-date, because of the permanent changes

done by different authorities on the large number of

services. Currently the Estonian e-government in-

formation system integrates more than 2000 atomic

services from about 100 organizations (Maigre and

Tyugu, 2011).

A solution to the complexity problem was intro-

ducing hierarchy in the service model. Services of

each ministry were based on its own database and

were kept up-to-date and compatible by the ministry

itself. Services of a ministry were collected into

a metaclass that became a component of a general

model (Grigorenko and Tyugu, 2012). Figure 4 shows

a model that includes components for Vehicles Reg-

istry, Business Registry, Population Registry, Migra-

tion Registry and Statutory Pension Insurance. Only

selected data were made public for each component,

and the general service model became comprehen-

sive. Figure 4 includes in the left upper corner a

BPEL component. This is a superclass needed for

control of the synthesis of a service in BPEL for-

mat. (It was possible also to create WSDL format

by using a component WSDL as the superclass.) In

CoCoViLa, schemes are also metaclasses. For every

scheme it is possible to deﬁne a superclass that is a

metaclass which will be able to manipulate scheme

objects and pass the data between objects using spe-

cial constructs. We present here in an abbreviated way

an example of synthesis of a service taken from (Grig-

orenko and Tyugu, 2012). Figure 4 is just a speciﬁ-

cation of this problem. The goal is to ﬁnd a notary’s

home address and number of his cars not older that 10

years from a given document number that was related

to the notary. This goal is formalized as

DocumentNumber.data ->

PopulationReg.address,

Count.size

The synthesized algorithm is:

documentNumber->

notaryNationalIDCode {toimiku_dokument};

Figure 4: Hierarchical service model of the Estonian e-

government.

(BusinessReg)

nationalIDCode->

firstName, lastName {RR405IsikNimi};

(PopulationReg)

nationalIDCode, firstName, lastName ->

address {RR57}; (PopulationReg)

nationalIDCode->

listOfVehicles {paring22}; (VehicleReg)

listOfVehicles->

listOfSelectedVehicles {select}; (Main)

listOfSelectedVehicles->

size {count}; (Main)

The experiments showed that model driven ap-

proach could be used in synthesis of public services

by experts responsible for creation of new services.

Practical application of the method would require

the application of some essential organizational mea-

sures.

6 BOOTSTRAPPING CoCoViLa

It is natural to use MDE in development and applica-

tion of domain-speciﬁc languages, and there are nu-

merous tools, especially simulation tools, that use this

approach (Tolvanen and Kelly, 2009). Examples pre-

sented above demonstrate that CoCoViLa is not an ex-

ception in this sense. However, our goal is to expand

the application domain of CoCoViLa for general-

purpose software development. This requires a differ-

ent software technology. In particular, when software

components are developed for one project, one can-

not expect that these components will be reused many

times, because they may be needed only in this ongo-

ing project, although the reuse is recommendable in

the future projects. The effort for developing compo-

nents should be minimal. Besides that, no restrictions

can be accepted on using a programming language in

implementation of components, because the technol-

ogy must be generally applicable. We are in process

ACaseStudyofCombiningCompositionalandObject-orientedSoftwareDevelopment

205

Figure 5: Model of CoCoViLa.

of ﬁne-tuning and documenting the respective tech-

nology. As a test case for the technology we have

chosen the development of a successor of CoCoViLa

itself that we will call CCV.

When beginning this project, we had already

source code of CoCoViLa, that consisted of 240 Java

classes, totally about 30K lines of code. These classes

had been developed in Java without any restrictions

on programming. Our intention was to use these

classes as much as possible for the new version of Co-

CoViLa.

We had no intention of changing the functional-

ity of the system. So we had an essential part of

the requirements speciﬁcation of CCV in the form of

documentation of the existing version of CoCoViLa.

The ﬁrst design step of the project was developing a

model of CCV. This step was easy to perform, be-

cause we had already a conceptual description of the

existing system which could be used for CCV as well.

We decided to start with a high-level model of CCV,

including only a small number of components with

well-deﬁned functionality. Information ﬂow between

the components was also made precise. This pro-

cess showed some design faults in the existing system

(hidden data paths, etc.). The high level components

of both CoCoViLa and CCV were Editor, Parser,

Planner, Generator and AlgorithmVisualizer.

The design step gave a model that was drawn in

the window of the existing CoCoViLa scheme editor

as shown in Figure 5. This scheme shows compo-

nents, types of their inputs and outputs, and connec-

tions between the components. Developing graphics

of components, and writing their metainterfaces was

an easy task using the existing CoCoViLa class editor.

Editor is a large component responsible for in-

teraction with a user, visual interface and transforma-

tion of graphical representation of the software model

into a textual speciﬁcation. It will be reasonable to

Figure 6: Metainterface of Parser.

develop a detailed model of this component in the fu-

ture. The speciﬁcation has a well deﬁned type with

syntax brieﬂy introduced in Section 2, but for the im-

plementation it is just a Java type String. Our tech-

nology prescribes showing both types in such a case,

as can be seen from Figure 5.

Parser is a component that transforms the speciﬁ-

cation from a textual speciﬁcation into an internal data

structure speciﬁed by a Java class Problem. This data

structure is mainly a large graph that is a representa-

tion of metainterfaces of all unfolded components. It

includes also a goal – names of the data items from the

speciﬁcation that must be computed by the program.

The Problem class has been designed for the needs

of Planner. If planning algorithm changes, then this

data structure may have to be changed as well.

Planner is the component that synthesizes the al-

gorithm for computing the goal. It uses only Problem

instance as the input. An algorithm of the planner

has been developed gradually through the years, and

its present version is described in (Grigorenko and

Tyugu, 2012). Type of the output of Planner is de-

scribed by Java class EvaluationAlgorithm. This

output represents only a structure of the synthesized

algorithm.

Generator transforms the

EvaluationAlgorithm into Java code. It uses

the instance of Problem to obtain and add input

arguments into the generated program.

AlgorithmVisualizer is included in the model

of CCV for supporting the debugging process, and it

is not needed for the code development itself.

The next step of the design was to write metain-

terfaces of components. It was reasonable to do this

already in Java, introducing empty methods with cor-

rect signatures in the metaclasses, if needed. Figure 6

shows a metainerface for Parser, and also one sim-

ple method getMainClassName for extracting a name

of metaclass from a speciﬁcation. The metainterface

shows that problem can be constructed in three steps

speciﬁed by the following axioms:

MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

206

spec -> mainClassName{getClassName};

spec, mainClassName, packagePath ->

classList{makeClassList};

classList,mainClassName->problem{makeProblem};

When designing metainterfaces, we had to decide

how to use the existing code. We decided to fol-

low the design of CoCoViLa as much as possible. In

the case of Parser, this meant the usage of an in-

termediate data structure of type ClassList. This

decision, in its turn, permitted to use the methods

makeClassList and makeProblem in the implemen-

tation of the Parser metaclass without any changes.

As we can see from the example of Parser,

the design of metainterfaces required some analy-

sis of the CoCoViLa source. It included a private

class Synthesizer that controlled the whole program

construction process, and used other classes where

needed. It was obvious that the existing classes could

not serve immediately as implementations of compo-

nents of the new model. An interesting question was,

how much changes were needed. It came out that

only minor changes of code were needed for imple-

mentation of methods after careful design of metain-

terfaces. This work was performed in two days by a

programmer who had an acquaintance with the Co-

CoVila code.

7 CONCLUSIONS

We have shown here on three examples how a tool

supporting the usage of Java classes supplied with

logical speciﬁcations can be used in compositional

programming. The ﬁrst example concerns a practi-

cally important case of development and usage of a

domain speciﬁc visual language. It demonstrates also

the scalability of the method – a hierarchical speciﬁ-

cation that after unfolding has thousands of interface

variables gives 8920 lines of synthesized code in one

second. The second example is about automatic com-

position of services. Atomic services that are com-

ponents have to be collected in large service models

ﬁrst, and the models are used then for specifying the

services to be synthesized. From our point of view,

the most important is the third example. This demon-

strates the feasibility of using the tool in a software

development project where domain speciﬁc language

has only a secondary role. The main domain speciﬁc

asset in this case is a system model that can be used as

a speciﬁcation for composing the software. This en-

ables us to separate compositional speciﬁcation from

implementation, and is useful for organizing a soft-

ware project.

ACKNOWLEDGEMENTS

This research has been partially supported by the Eu-

ropean Regional Development Fund (ERDF) through

Estonian Center of Excellence in Computer Sci-

ence (EXCS), target-ﬁnanced research theme No.

0140007s12 of the Estonian Ministry of Education

and Research, and the project No. 3.2.1201.13-0026

Model-based Java software development technology.

REFERENCES

Brambilla, M., Cabot, J., and Wimmer, M. (2012). Model-

driven software engineering in practice. Synthesis

Lectures on Software Engineering, 1(1):1–182.

Constable, R. L. (1971). Constructive mathematics and au-

tomatic program writers. In Proceedings of the IFIP

Congress, pages 229–233. North-Holland.

Green, C. (1980). The application of theorem proving to

question-answering systems. Outstanding disserta-

tions in the computer sciences. Garland Pub.

Grigorenko, P., Saabas, A., and Tyugu, E. (2005). Visual

tool for generative programming. In ACM SIGSOFT

Software Engineering Notes, volume 30, pages 249–

252. ACM.

Grigorenko, P. and Tyugu, E. (2012). Higher-order attribute

semantics of ﬂat declarative languages. Computing

and Informatics, 29(2):251–280.

Grossschmidt, G. and Harf, M. (2009). Coco-sim–object-

oriented multi-pole modelling and simulation environ-

ment for ﬂuid power systems. part 2: Modelling and

simulation of hydraulic-mechanical load-sensing sys-

tem. International Journal of Fluid Power, 10(3):71–

85.

Kelly, S. and Tolvanen, J.-P. (2008). Domain-speciﬁc mod-

eling: enabling full code generation. Wiley. com.

Kent, S. (2002). Model driven engineering. In Integrated

formal methods, pages 286–298. Springer.

Maigre, R., K

ungas, P., Matskin, M., and Tyugu, E. (2009).

Dynamic service synthesis on a large service models

of a federated governmental information system. In-

ternational Journal On Advances in Intelligent Sys-

tems, 2(1):181–191.

Maigre, R. and Tyugu, E. (2011). Composition of services

on hierarchical service models. Information Mod-

elling and Knowledge Bases XXIII, Frontiers in Ar-

tiﬁcial Intelligence, 237:110–129.

Manna, Z. and Waldinger, R. (1993). The deductive foun-

dations of computer programming: a one-volume ver-

sion of the logical basis for computer programming.

Addison-Wesley Longman Publishing Co., Inc.

Matskin, M., Maigre, R., and Tyugu, E. (2007). Com-

positional logical semantics for business process lan-

guages. In Internet and Web Applications and Ser-

vices, 2007. ICIW’07. Second International Confer-

ence on, pages 38–38. IEEE.

ACaseStudyofCombiningCompositionalandObject-orientedSoftwareDevelopment

207

Matskin, M. and Tyugu, E. (2001). Strategies of structural

synthesis of programs and its extensions. Computers

and Artiﬁcial Intelligence, 20(1).

Mints, G. and Tyugu, E. (1990). Propositional logic pro-

gramming and the priz system. The Journal of Logic

Programming, 9(23):179 – 193.

Santos, A. L., Koskimies, K., and Lopes, A. (2010). Au-

tomating the construction of domain-speciﬁc model-

ing languages for object-oriented frameworks. Jour-

nal of Systems and Software, 83(7):1078–1093.

Software, I. (2003). Special issue on model-driven develop-

ment, volume 20.

Tolvanen, J.-P. and Kelly, S. (2009). Metaedit+: deﬁning

and using integrated domain-speciﬁc modeling lan-

guages. In Arora, S. and Leavens, G. T., editors, OOP-

SLA Companion, pages 819–820. ACM.

MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

208