A Simple Erlang API for Handling DDS Data Types and Quality of

Service Parameters

Wafa Helali, Khaled Barbaria and Belhassen Zouari

LIP2 Lab, University of Tunis, El Manar, Tunis, Tunisia

Keywords:

Middleware, Functional Programming, DDS, Erlang.

Abstract:

The choice of the programming language impacts the efﬁciency of the application and the robustness of the

code. The characteristics of Erlang as a functional programming language supported distributed real time

computing allowed us to propose eDDS: an Erlang based middleware compliant to the Data Distribution

Service (DDS) standard that providing a strong Quality of Service (QoS) support. When the performance and

the compliance to the norm have been easy achieved in particular on deﬁning and setting QoS parameters, the

lack of efﬁcient and user-friendly support for data type management has been noticed. In this paper, we will

explain this type checking problem and how we solved it.

1 INTRODUCTION

Programming distributed applications is a complex

activity. These applications are characterized by a

great hardware (physical networks, hardware plat-

form) and software (operating systems, programming

languages, etc.) heterogeneity . The design of such

applications becomes more complex when we talk

about real time distributed applications. Such sys-

tems now present in many areas, especially in the

aerospace, defense, power systems and industrial con-

trol.

To facilitate the development of such applications,

it is recommended to choose the adequate implemen-

tation support. In fact, programming models and lan-

guages impact the ability to easily write clear and re-

liable programs. Like presented in (Emmanuel Chail-

loux, Pascal Manoury and Bruno Pagano, 2001), the

simplicity of a programming language is dependent

on many level of abstraction: Abstraction from the

machine and the operational model; Abstract errors:

fault tolerance and error handling; Abstract compo-

nents: a complex application can be subdivided into

autonomous subprograms or components that can be

reused in other context; Interoperability between the

languages can be also a kind of abstraction: the possi-

bility to communicate with other programs written in

other programming language.

These elements motivate the choice of the func-

tional programming paradigm (Hudak, 1989) which

brings a high level of abstraction. This paradigm

use functions as base of computations. A function

is deﬁned as ﬁrst class citizens: it can be stored,

composed and even passed as parameters. Moreover,

functional languages provide the programmer with fa-

cilities to abstract data-types and easily support pat-

tern matching. Some of them are optimized to spe-

ciﬁc research and industrial objectives (e.g. handle

concurrency, support distribution, control execution

time, etc.). Functional programs rely on automatic

allocations and the heavy use of recursion. Conse-

quently, they can be written and reused, executed and

redeployed more easily on central, parallel and dis-

tributed architectures. This is the reason why various

functional programming languages are used to pro-

gram large-scale industrial systems such as the Ama-

zon SimpleDB documentation and the Erlang based

Web server yaws, as well as the Facebook instant

messaging service.

The research work presented in this paper mainly

uses Erlang ( Ericsson Computer Science Laboratory,

1980) as a framework. This concurrent distributed

real-time language, whose story is already old, still at-

tracts many developers and designers especially from

mobile technologies. We are focused in ﬁrst step

on how to create a simple API generated automati-

cally to deﬁne and set quality of service parameters

in our eDDS middleware: the ﬁrst Erlang support of

the DDS speciﬁcation. In other hand, Erlang is a dy-

namically typed language. This characteristic can be

an advantage and an inconvenient at the same time.

In this paper we show how we have beneﬁted from

Helali W., Barbaria K. and Zouari B..

A Simple Erlang API for Handling DDS Data Types and Quality of Service Parameters.

DOI: 10.5220/0005381600190026

In Proceedings of the 10th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE-2015), pages 19-26

ISBN: 978-989-758-100-7

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

this feature and we present our solution to solve the

type checking problem caused by the lack of a strong

typing system in order to make our middleware more

reliable.

The rest of the paper is structured as follows. In

the next two sections we brieﬂy review the basis of

our work in order to put it into context. In the sec-

tion 4, we describe our Erlang DDS API for deﬁning

and setting QoS parameters and then we present the

Erlang type checking problem and how we solve it.

Some closely related work are presented in section 5.

Our concluding remarks are presented in section 6.

2 DATA DISTRIBUTION SERVICE

DDS (Data Distribution Service) is speciﬁed by the

OMG (Object Management Group , 2007) to satisfy

the requirements of real-time (large scale) distributed

applications, which have direct interaction with real-

world objects, such as air-crafts, trains, stock trans-

actions, and defense engines. This standard presents

an evolved technology to exchange data in a dis-

tributed context. It is based on a high-leveldata model

where the unit of transmission is the data instead of

objects reference(CORBA reference passing)(Object

Management Group, 2012) or messages (CORBA by

value and MOM such as JMS).

This underlying model, focused on data, allows

to identify and control the access to all data which

circulate in the system through a Global Data Space

(GDS). Therefore, the integration of applications be-

comes simple and easy: the participants using DDS

can read an write data efﬁciently and naturally with

a typed interface that allows the developers to spec-

ify only the data that will be transferred or read and

the associated quality requirements , regardless of the

other low level considerations related to the effective

dissemination of this data. The communication be-

tween the distributed nodes is accomplished with the

aid of the following entities: Domain, DomainPartic-

ipant, Publisher, DataWriter, Subscriber, DataReader

and Topic. These entities, depicted in Figure 1 are

described below. Domain is a construct that binds

all the applications entities able to interact with each

other. An application can participate in several do-

mains at the same time. Domain is consequently a

means to easily deﬁne independent partitions in the

distributed system. Partitions can be deﬁned to iso-

late applications running on the same physical com-

puter from each other.

The DomainParticipant acts as container for all

other DCPS (Data Centric Publish Subscribe) entities.

It represents the local membership of the application

Figure 1: DDS Entities (Object Management Group , 2007).

in a Domain. It is responsible for creating Publishers,

Subscribers and Topics.

Topics provide the basic connection point between

publishers and subscribers. A topic is identiﬁed by

a unique name within a Domain. It is associated to

a speciﬁc data type that can be communicated when

publishing or subscribing on this Topic.

The Publisher is the object responsible of data dis-

semination. A publisher can send data of differ-

ent types. It includes several DataWriters, each

DataWriter is associated with a speciﬁc data type. It

is the object which allows applications to update the

data values that will be published under a given Topic.

The Subscriber receives the published data that cor-

responds to its subscriptions. It makes it available to

the application through many DataReaders, DDS as-

sociates a DataReader to each speciﬁc data type.

3 ERLANG: DYNAMICALLY

TYPED FUNCTIONAL

DISTRIBUTED LANGUAGE

Erlang is a concurrent functional programming lan-

gage developed at Ericsson in 1980 and intended for

the implementationof its telecommunicationsystems.

It is successfully used in major industrial projects and

large scale applications such as SimpleDB document,

databases of Amazon and the yaws HTTP server, as

well as Facebook. Erlang is both a language and run-

time environment. It provides many libraries grouped

under the name of OTP (Open Telecom Platform).

It possesses qualities that simplify program design

and ensures efﬁcient and comfortable design and de-

velopment of applications: (Cesarini and Thompson,

2009):

• High-level Constructs. Erlang is a declarative

language, dynamically typed. There are no as-

signments nor mutable data structures. An Erlang

program can contain several data types including

ENASE2015-10thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

atoms, numbers, and process identiﬁers as well as

compound data types like lists, tuples and records.

Functions are ﬁrst-class data: a function can be

stored in a list, returned by a function, or commu-

nicated between processes. Erlang functions can

be deﬁned as a set of clauses or equations. The se-

lection of a clause is done by the pattern matching

mechanism.

• Memory Management. The management of

memory in Erlang (allocation and deallocation)

is done automatically. Each process has its own

garbage collector. This makes development pro-

gram easier and faster by eliminating program-

ming errors such as memory deallocation and

buffer overﬂows.

• Concurrency. Unlike other languages like C or

Java that directly use the threads of operating sys-

tem, Erlang manages the created processes by the

virtual machine (VM). Each process handles its

own memory space and runs independently of the

others. The processes communicate with each

other by using a message exchange mechanism.

Response time of systems based on this mech-

anism is about some microseconds regardless of

the system load .

• Distribution. Erlang processes are created by the

virtual machine. Multiple virtual machines (Er-

lang nodes) can be connected to each other and

the processes running on different nodes commu-

nicate with each other by using the same primi-

tive message sending that used by processes in the

same node.

• Robustness. Erlang provides mechanisms for

handling errors and exceptions: Erlang process

can be connected together, if one crashed, the

other will be informed. An other mechanism pro-

vided by Erlang/OTP is the supervision that can

be used to monitor and handle process termina-

tion. Using these techniques makes Erlang pro-

grams shorter and easier to understand by sepa-

rating the speciﬁc code of the application from the

code that manages the dysfunctions.

4 BUILDING SAFE, EFFICIENT

DISTRIBUTED SYSTEM WITH

EDDS

The main role of middleware is to simplify the de-

velopment of distributed applications by providing

an API for an easy and comfortable programming.

eDDS provides a simple API to create DDS entities,

deﬁne and set QoS policies. In other hand, middle-

ware should help the developers of the distributed sys-

tems during the development of these applications. In

this section we present how we respect these require-

ments.

4.1 Presentation of eDDS

eDDS is the ﬁrst Erlang implementation of the DDS

speciﬁcation. eDDS is built upon CORBA architec-

ture. DDS entities are implemented as CORBA ob-

jects deployed on various communicating nodes. Fig-

ure 2 shows the architecture of eDDS: an intermediate

server (Repsitory) allows publishers and subscribers

to discover each other. It acts as an intermediary that

matches compatible publishers and subscribers (wrt

Topic and QoS). When a client requests a subscrip-

tion for a given Topic, the server locates this Topic

and informs all existing DataWriter for the location

of the new DataReader. The communication between

nodes is based on the Erlang message passing mecha-

nism: the data will be published as an Erlang message

from DataWriters to DataReaders.

Figure 2: The Architecture of eDDS.

4.2 Deﬁning and Setting QoS

Parameters on eDDS

The most important advantage of DDS is the pos-

sibility to tailor and control a wide range of qual-

ity of service parameters (Object Management Group

, 2007). These QoS policies are multiple and di-

verse, they address different areas of middleware be-

havior and several aspects of data like: data avail-

ability ( Durability, Lifespan, History); data de-

livery (Reliability, Destination Order, Ownership);

data timeliness (Latency

Budget, Deadline) and max-

imum resources used in the system (Resource Limits,

Time

Based Filter).

QoS management is one of the key distinguishing

features of the DDS when compared to other pub/sub

standards. These QoS parameters allow to specify ex-

actly how the information should ﬂow between pub-

lisher and subscriber sides: application developers

only indicate ’what’ they want to publish and spec-

ify the QoS parameters that should be respected, but

they are not responsible for ’how’ this QoS should be

ASimpleErlangAPIforHandlingDDSDataTypesandQualityofServiceParameters

achieved (Corsaro et al., 2006). These QoS policies

are represented in the speciﬁcation like IDL structures

that will be transformed as Erlang records after com-

pilation. A record is an Erlang data type structure

used to store a ﬁxed number of elements. The next

example represents the transformation of the presen-

tation QoS parameter in Erlang record after compila-

tion.

The manipulation of Erlang records can be difﬁ-

cult especially for the developers that are not familiar

with this language. This data structure requires the

use of numerous symbols like ”#”, ”(”, ”{”. Thus, it

is useful for any Erlang program which uses records

to deﬁne the methods of treating, reading and writ-

ing the record element. Our idea consists in using an

API that simplify the use of records and make it more

reliable (Trung, 2009).

% name of the QoS policy passed as parameter

type(Record) when is_records (Record,

’DDS_PresentationQosPolicy’)->

{ok,’DDS_PresentationQosPolicy’}.

% fields of the given QoS parameter

fields(’DDS_PresentationQosPolicy’)->

[access_scope,coherent_access,ordered_access].

% set/get access\_scope value of the PreQos

set(Record,access_scope,Value)

get(Record,access_scope)

This API is generated automatically from the records

by applying the ”parse” function to the DDS.hrl ﬁle

that contains deﬁnitions of all DDS QoS policies. The

syntactic analysis is made in two stages: the ﬁrst step

serves to extract all attributes (ﬁle, elements and sub-

ﬁelds) which compose the header ﬁle. Each element

of this list will be also analyzed using the ”parseRe-

cord” function. The result of applying this function to

the PresentationQos policy is presented in Figure 3.

Figure 3: Generate setget function (step1).

Figure 4: Generate setget function (step2).

In the next step, the result variables (RecordName,

RecordFields) will be used as parameters for the gen-

erative functions which are responsible for creating

all the necessary functions to treat the QoS parame-

ters. Then, it should collect all the creating functions

by using the function ”listﬂatten” and then write them

on the API ﬁle by using the function ”write” of the

”ﬁle” module. Figure 4 shows how to generate the

functions related to the Presentation QoS parameter.

To ameliorate this API we generate an other function

that permit to setting all ﬁelds of a given QoS param-

eter at the same time like presented in the next listing.

set_PresentationQosPolicy(Record, access_scope,

V_as,coherent_access,V_ca,ordered_access,V_oa).

The next example shows the difference of using this

API before and after amelioration. We purpose that

initial PresentationQoS parameter is ”PreQoS” and

we want to change their three ﬁelds (access

scope,

coherent

access, ordered access). By using the new

setting function we can change the QoS parameter in

one line of code. The quality of service parameters in

eDDS are usually represented by complexrecords and

contain multiple ﬁelds. That is why, it is important to

make our API handling this kind of records. Like pre-

sented below, we generate two functions that make

Figure 5: Setting the Presentation QoS parameter.

ENASE2015-10thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

setting and getting subﬁelds for complex records.

getSF( Record, Field,sub_field).

setSF(Record, Field,sub_field,V).

The following example present how we use these

functions to set the presentation parameter in the

QoSPublisher policy (we want to change the value of

ordered

access to false ). This PublisherQoS policy is

a complex record: the presentation parameter is also a

record. Without our API the setting operation would

make on two steps: we should create the new pre-

sentation value before make it into the new PubQos

value. This will be reduced at one line of code by

calling the ”setSubField” function (setSF).

Figure 6: Setting the Presentation parameter on the

QoSPublisher policy.

4.3 Beneﬁt of Dynamic Typing: Generic

DataWriter

In computer science, a data type, deﬁnes the possi-

ble values that can be given to the data and the op-

erators that can be applied on. Dynamic typing is a

characteristic for many programming languages such

as Erlang. In this paradigm, the veriﬁcation of types

does not happen at the compilation step but it is left at

run time. This simplest level provides lower develop-

ment costs and ﬂexible programming. It is important

to note that this is different than typeless: both dy-

namically and statically typed programming language

are typed (Tratt, 2009).

In contrast to other implementation of DDS ( Java,

c, c++) that require to create a speciﬁc DataWriter

(resp DataReader) for each new data type. On eDDS,

we took advantage of the possibility to abstract data

types given by Erlang to develop only one generic

Figure 7: Generic DataWriter.

DataWriter (resp one generic DataReader) for all data

types. More precisely, this DataWriter (resp this

DataReader) has a generic ”write” (resp a generic

”read) function by with an application can write (resp

read) any data for any data type. The participant

application should specify the desired data type as

an argument when creating the DataWriter or the

DataReader. In the next example, we present how to

create DataWriter for the cricle data type respectively

in eDDS and in OpenDDS (a C DDS implementation)

(Object Computing Inc (OCI), OpenDDS, ).

• Generic DataWriter in eDDS:

Datawriter=edds:create_datawriter(Pub,

DP,CircleTopic,Qos,Listener,Mask),

edds:write(DataWriter,circlevalue).

• Speciﬁc DataWriter in OpenDDS:

DDS::DataWriter_var writer = pub->

create_datawriter(circleTopic,QOS,Lis,Mask);

Circle::CircleDataWriter_var circle_writer

= Circle::CircleDataWriter::_narrow(writer)

circle_writer->

write(circlevalue, DDS::HANDLE_NIL);

4.4 Inconvenient of Dynamic Typing:

Typechecking Problem

4.4.1 Presentation of the Problem

As presented on the previous section, eDDS deﬁnes

a generic DataWriter (resp DataReader) for all data

types. However, having a single generic DataWriter

not avoid the need to check the data types. Before

sending any data (resp receiving any data) we must

verify its type. That’s why, type checking of sent and

received data is required. The next example present

this type checking problem: ”write” function will ac-

cept any data type given as parameter. This is due to

that the transmission of data is doing in the form of

bit sequences.

ASimpleErlangAPIforHandlingDDSDataTypesandQualityofServiceParameters

Figure 8: Type checking problem.

4.4.2 The Solution: Check Function

Data types are represented as Erlang records. All data

types used in the global data space are registered on a

header ﬁle located on the server. However, each par-

ticipated application has its local data type ﬁle that

contains data types which will be used by this appli-

cation to publish or receive data. We have created a

validator which use the same parsing technique pre-

sented previously and generates automatically check

functions that take on parameters the data and the

type that will be checked(check ( Data, Type)). These

functions can be called by the function write or read

to check data before make it availableto the user: data

type must be the same deﬁned on the DataWriter (or

the DataReader). The two Figures ”7” and ”8” present

the principals steps to generate this function. We take

for example the TempSensor data type.

-record(sensor,{

id:: integer(),

temp :: integer(),

press :: integer()}).

In fact, the usefulness of this parsing tech-

nique can not end here. There are an other

type of checking function based on this principe:

Figure 9: Generate check function (step1).

Figure 10: Generate check function (step2).

check type exists(name, HeaderFile) function to

check whether the type name given in parameter al-

ready exists or not. Before creation of any new data

type, the system must verify if there is already data

type have the same name. This function is used

also when creating a new topic and we want to ver-

ify if data type name used is registered in the local

DataType

ﬁle.

check_type_exists(Name, HeaderFile) ->

L=get_recordnames(HeaderFile),

find_element(Name,L).

4.4.3 Evaluation

In this section we will show the importance of using

the check function in our eDDS API to make Erlang

based DDS applications more reliable. We present

below the differences between the two cases: an ap-

plication d’ont use an explicit type checking and an

other that will use an explicit type checking.

• Without Explicit Type Checking. In the next ex-

ample we want to show the risks that can meet

developers of eDDS applications without check-

ing the type of data that will be sent or received.

In Publication Side, We create a CircleTopic that

uses the Circle data type and we associate to it

a DataWriter. We did the same thing in the sub-

scription side and we associate a DataReader to

the CircleTopic. As shown in this example, we did

not sent a circle as expected but a square sample.

We notice that no error is marked in the develop-

ment stage or in the phase execution: The square

date is received by the DataReader.

ENASE2015-10thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

Figure 11: Sending data without explicit type checking.

• With Explicit Type Checking. In this case we

will verify the data before publication. We mod-

iﬁed the write function like presented below. It

must recover the data type used by the concerned

datawriter and then we call the check function and

passing as parameters the type name and the data.

If check function returned true, the data will be

send to the datareader. If not, an error message

will be displayed.

edds: write (Writer,Data)->

%...

if (check(Data,Type) == true) ->

’DDS_DataWriter’:write(Writer,Data);

true-> io:format("\n ### Invalide Data ###")

end.

Figure 12: Sending data with explicit type checking.

Like the previous example, We create a

DataWriter and a DataReader associated to

the CircleTopic and we write a square data

instead of a circle data. As noticed below, this

data has not published and nothing received on

the subscription side. For more reliability, it

is recommend to make the same modiﬁcation

of the write function in the read function on

the subscription side to check the received data

before making it available to the application: the

data should respect the type of the concerned

Datareader.

4.4.4 Discussion

While DDS data types are represented in Erlang as

records, it is logical to think of the BIF is

record to

verify these types. A simple example presented be-

low shows the difference between check and is

record

functions. This BIF handles only the simple case of

records. It takes as parameters the data and a record

name and returns a boolean value to indicate if this

data is an instance of this record or not. But this BIF

suffers same drawbacks: it does not work correctly if

in the record declaration we speciﬁed also the types

of record ﬁelds. Our check function is more accurate.

It will solve this problem. We can take for example

the Sensor record deﬁned previously.

Data1 =#Sensor{i d =1 , temp =30 , press =10}

Data2 =#Sensor{i d =2,temp = temperature,press=10}

is_record(Data1,Sensor) %% true

is_record(Data2,Sensor) %% true

check(Data1,Sensor) %% true

check(Data2,Sensor) %% false

In an other hand, this aspect of dynamic typing and

the fact that not having the veriﬁcation type during

the compilation step is also recommended by DDS. In

2012, the OMG bring out an extensible speciﬁcation

of DDS just to adapt this principe (Object Manage-

ment Group , 2012). They motioned that is preferable

to have a dynamic API that allows type deﬁnition, as

well as publication and subscription data types with-

out compile-time knowledge of the schema.

5 RELATED WORK

• Erlang Type Checking Systems

There are many attempts and approaches to en-

hance Erlang with type checking system, some

of them are well known on the Erlang commu-

nity. (Frank Huch, 2001) presented an approach

for the formal veriﬁcation of Erlang programs us-

ing abstract implementation and model checking;

(Chanchal Kumar Roy, Thomas Noll and Banani

Roy, 2006) provide a contribution to the formal

modeling and veriﬁcation of programs written in

ASimpleErlangAPIforHandlingDDSDataTypesandQualityofServiceParameters

Erlang: mapping to the lambda calculus; (Thomas

Noll, Lars ake Fredlund and Dilan Gurov, 2002)

are developed the Erlang Veriﬁcation Tool; Dia-

lyzer (Erlang, 2007): A Discrepancy Analyzer for

Erlang program which is used in various telecom-

munication projects. It is a defect detection tool

that use a static analysis to detect anomalies+ in

the Erlang code. It’s part of the Erlang/OTP dis-

tribution since 2007; Typer (Tobias Lindahl Kon-

stantinos Sagonas, 2005): An automatic type an-

notator for Erlang program based on type infer-

ence of success typing. It check speciﬁed type

against the inferred type. It is part of Erlang/OTP

since 2008.

• The Scala API for DDS

Scala stands for scalable langage, it is new lan-

guage (2003) that blend Object oriented and func-

tional constructs into a statically strongly typed

language with sophisticated type inference. (Cor-

saro, 2012) created a scala API for DDS. In con-

trast of our eDDS that completely based on Er-

lang, Escalier is based on the Open Splice Mid-

dleware. Also This API is very simple to use

specially when creating DDS entities and setting

Qos parameters. Like the principe of eDDS, this

approach used the notion of Type parameterized

of Scala (Martin Odersky, Lex Spoon, and Bill

Venners, 2008) to create a generic DataWriter

(resp DataReader). This principe alows to deﬁne

many speciﬁcs types with one generally written

class. If we take the same example of TempSen-

sor: the user can write any data not only those its

type is TempSensor. So there is a problem of ver-

iﬁcation of data that will be transmitted.

6 CONCLUSIONS

To facilitate the development of distributed real time

systems that require various quality of service aspects,

such as predictable performance, secure communica-

tions, availability and fault tolerance. An Applica-

tion Programming Interface is required to abstract the

platform speciﬁc details of the underlying QoS im-

plementation. This paper shows how to create a sim-

ple DDS API by taking advantage of a functional pro-

gramming language such as Erlang to deﬁne and set

QoS policy. In fact, we used a record parsing tech-

nique to generate automatically the desired API. This

technique is adopted in many area in eDDS specially

to solve Erlang problem type checking caused by its

dynamically typed characteristic in order to respect

the nature of DDS that provides a strong typed dis-

tributed system. As a future work and in order to im-

prove our API, we can make the possibility to add or

remove ﬁelds in a given data type like presented in the

Extensible and Dynamic Topic Types for DDS speci-

ﬁcation.

REFERENCES

Ericsson Computer Science Laboratory (1980). ERLANG

programming language. http://www.erlang.org. Ac-

cessed: 24-07-2014.

Cesarini, F. and Thompson, S. (2009). Erlang program-

ming. O’Reilly.

Chanchal Kumar Roy, Thomas Noll and Banani Roy

(2006). Towards Automatic Veriﬁcation of Erlang

Programs by Lambda Calculus Translation.

Corsaro, A. (2012). High performance distributed comput-

ing with DDS and Scala. In PrismTech Corp.

Corsaro, A., Querzoni, L., Scipioni, S., Piergiovanni, S. T.,

and Virgillito, A. (2006). Quality of Service in Pub-

lish/Subscribe Middleware. Chapter in Global Data

Management.

Emmanuel Chailloux, Pascal Manoury and Bruno Pagano

(2001). Developing Applications With Objective

Caml. Editions O’REILLY.

Erlang (2007). The DIscrepancy AnaLYZer for ER-

lang applications. http://www.erlang.org/doc/man/

dialyzer.html.

Frank Huch (2001). Veriﬁcation of Erlang Programs

using Abstract Interpretation and Model Checking.

In Proceeding ICFP ’99 Proceedings of the fourth

ACM SIGPLAN international conference on Func-

tional programming, pages 261 – 272.

Hudak, P. (1989). Conception, evolution, and application

of functional programming languages. ACM Comput.

Surv., 21(3):359–411.

Martin Odersky, Lex Spoon, and Bill Venners (2008). Pro-

gramming in Scala. http://www.artima.com/pins1ed/.

Object Computing Inc (OCI), OpenDDS. http://

www.opendds.org.

Object Management Group (2007). Data Distribution Ser-

vice for Real-time Systems Speciﬁcation. version 1.2.

Object Management Group (2012). Extensible and Dy-

namic Topic Types for DDS. version 1.0.

Object Management Group (2012). Common Object

Request Broker Architecture (CORBA). http://

www.omg.org/spec/CORBA/3.3. version 3.3.

Thomas Noll, Lars ake Fredlund and Dilan Gurov

(Springer-Verlag 2002). Erlang veriﬁcation tool.

Tobias Lindahl Konstantinos Sagonas (2005). TYPER: A

Type Annotator of Erlang Code.

Tratt, L. (2009). Dynamically typed languages. Advances

in Computers, 77:149–184.

Trung (2009). Record introspection at compile time. http://

erlangexamples.com/tag/record/. Accessed: 28-11-

2014.

ENASE2015-10thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering