Modello B - Università degli Studi di Genova

Ministero dell'Istruzione dell'Università e della Ricerca
elementi mobili. Senza tale supporto è difficile modellare come un algoritmo si comporti quando la struttura della nuvola cambia e conseguentemente un'analisi
qualitativa non può essere effettuata se non sperimentalmente dopo che l'algoritmo è stato implementato.
Diversi tentativi per supportare l'evoluzione della struttura sono stati fatti: reti di Petri riflessive [CC07b], reconfigurable nets [BO98], nets-within-nets [CDMR05] e
reti come token [Val98]. In generale tutti questi approcci tranne le reti di Petri riflessive affrontano l'evoluzione codificando tutte le possibilità nel modello; questo
porta ad avere i) un modello che non rappresenta la realtà corrente ma che è inquinato da ciò che potrebbe accadere e ii) che difficilmente riesce a coprire tutte le
possibili evoluzioni. Le reti di Petri riflessive sfruttano la riflessione [Mae87] per separare il modello da come potrebbe evolvere ed è lo strumento perfetto per
modellare situazioni in cui l'evoluzione è regolata da leggi di distribuzione o è generata proceduralmente come nel caso delle nuvole.
Lavoro corrente. Da diversi anni si sta lavorando sulle reti di Petri riflessive [CC06,CC07b] e sulla loro applicazione alla riflessione [CC07a,CC08].
Testo inglese
The work of this group of researchers (unit of Milano) will be within Task 1 (Composition) and Task 2 (Interaction and Distribution).
In the following we review the state of the art of the research areas related to subtasks in which this unit is expected to be the main investigator, in particular the
current work which will be the starting point for the research.
Task 1 - Composition
SubTask 1.3 Evolution and refactoring
Nowadays, software evolution is a very hot topic [MBZR03, Fel03, BR00, MWD+05]. Many applications need to be updated or extended with new characteristics
during their lifecycle. Software evolution, as well as software maintenance, is characterized by its huge cost and slow speed of implementation. Typically the evolution
takes place by stopping the system, adapting it and finally restarting it; this process is unfeasible when the system is critical and basically cannot be stopped as in air
traffic control systems, banking systems, and so on.
In general, the right direction to face the system evolution during its execution (dynamic evolution) consists of i) postponing the evolution planning from design-time
to run-time, ii) separating the evolution crosscutting concern from the application code and iii) (semi-)automating the system evolution. Both reflection [Mae87] and
aspect-oriented programming [KHH+ 01] provide some mechanisms to overcome these problems.
Few reflective and aspect-oriented middleware [CSST99, Ran05, CSG06] have been investigated with the intent of tackling the problem of run-time evolution with
limited success. They have to face with the limited support of the development frameworks to dynamic changes to the software, e.g., Java [GJSB05], as well as many
others mainstream programming languages, supports only changes to the code but not to the schema of a class [PKS08], i.e., it is possible to add a statement to a
method but it is impossible to add a new method to a class impeding several kind of evolution.
Also static code evolution presents several problems: documentation typically do not evolve accordingly with the application code evolution [CPGS07], often is
necessary to change code that do not apparently affect by the change and break the module decomposition [KS04]. Currently both object- and aspect-oriented
techniques have several limits with respect to the evolution issue and need to be improved.
Current work. We are working on the evolution issue since a long time and started to face all the reported problems. In particular we have designed an alternative
aspect-oriented approach named Blueprint to face the evolution problem by freeing the modularization from the module syntax [CPA04, CPA05, CPA06, CP06,
CP07a, CP07b]; similarly we have extended Java and C# [CCC05b, CCC05a] meta-data facility (respectively in @Java and [a]C#) to support fine grained
annotations that can be used to co-evolve code and documentation [CPGS07].
SubTask 1.4 - Compositional language development
Domain Specific Languages (DSLs) are used to solve several problems, such as typesetting documents and code, to express and verify constraints and to coordinate
distributed computation.
In some cases, these are simply a bunch of programming features, useless standalone, embedded in a general purpose programming language or provided as external
libraries. More often, they are Turing complete programming languages devoted to a specific aim. In both cases there are some issues that hamper their
realization/usage: in the latter case, to implement and test a new DSL requires time and often it also has a steep learning curve; in the former case the learning curve
is smoother but performances and flexibility are often compromised. Moreover, in general, it is quite hard to tailor an existing DSL to the needs of a given problem or
to let coexist features coming from two or more DSLs into a single programming language.
To test new ideas in programming languages research area is often demanded to the definition/implementation of a DSL from an existing programming language via
rapid prototyping techniques, e.g., by using OpenJava [CTKI00], Javassist [Chi00] and so on. On the one hand this approach permits to focus on the new idea
implementation on the other hand it strictly relies on the extension of a language with new features but does not permit to reuse features and their implementation
from other languages.
In our view, the observed problems derive from the monolithic approach adopted to define and implement a programming language. Classic approaches [ASU86] to
programming language definition and to compiler designing are grammar-centric; grammars describe the language syntax and how a program written in that
language should be translated (syntax directed translation). Even if the compiling process is modularized in phases the language definition cannot, this, in our view,
is the major obstacle to render a programming language easily extensible.
Some attempts to have a more modular programming language definition and implementation has been done: Ziggurat [FS06], Linglet Transformation System
[Cle07], Polyglot [NCM03] and JastAdd [EH07]; but the provided modularity is limited and often refers only to the language definition and not to its
implementation.
Current work. In [CS09], we have started to design an alternative approach (named Hive) to DSL specification and implementation highly modular. Hive exploits the
slicing idea from HyperJ [OT01] to decompose the language definition and implementation in modules that can be freely composed.
Task 2 - Interaction and Distribution
SubTask 2.5 - Mobility and dynamic evolution
Nowadays, mobility is one of the key concepts that pervades everyday activity. Smartphones, palmtops and sensors are examples of mobile devices that can be
configured in highly dynamic networks. A number of these devices close enough to be reachable each other originates the so called cloud. Clouds are characterized
by an highly variability in composition over time: devices due to their mobility enter and exit from the reachability area of the other devices and therefore from the
cloud, i.e., the cloud layout is in a continuous evolution. Moreover mobile devices have several limitations such as battery and CPU performances so algorithms
coping with such limitations are necessary to route messages, to spread information around and to detect which devices can or cannot be reached.
Research in the area is quite vivacious [GPR08, BGPS06, WW07, SX05] but they badly cope with the high evolvability of the cloud. This is mainly due to the limited
support to layout evolution that the formalisms to model distribution provide, e.g., Petri nets [Rei85], pi-calculus [Mil99]. Without such a support it is hard to model
how an algorithm behaves when the cloud layout changes and consequently a quality analysis cannot be performed if not experimentally after the algorithm
implementation that means to spend time in realizing something that could be useless.
Several attempts to support layout evolvability have been done: reflective Petri nets [CC07b], reconfigurable nets [BO98], nets-within-nets [CDMR05] and nets as
tokens [Val98]. In general all of these approaches but the reflective Petri nets face the evolution issue by coding all the possible evolution in the model; this has a
couple of drawbacks: i) the model does not represent the current reality but it is polluted by what could be happen and ii) it is quite impossible to foresee all the
possible evolutions. Reflective Petri nets exploit reflection [Mae87] to separate the model from how it can evolve and it seems perfect to model situations where the
MIUR - BANDO 2008 - MODELLO B - 6 -