MINISTERO DELL'UNIVERSIT E DELLA RICERCA SCIENTIFICA E TE CNOLOGICA DIPARTIMENTO PER LA PROGRAMMAZIONE IL COORDINAMENTO E GLI AFFARI ECONOMICI - SAUS PROGRAMMI DI RICERCA SCIENTIFICA DI RILEVANTE INTERESSE NAZIO NALE RICHIESTA DI COFINANZIAMENTO (DM n. 10 del 23 gennaio 2001) PROGRAMMA DI RICERCA - MODELLO A Anno 2001 - prot. 2001011229 Parte: I 1.1 Programma di Ricerca di tipo: interuniversitario Area Scientifico Disciplinare: Scienze Matematiche ------------------------------------------------------------------------ 1.2 Titolo del Programma di Ricerca Testo italiano Architetture Software per infrastrutture di rete ad accesso eterogeneo (SAHARA) Testo inglese Software Architectures for Heterogeneous Access Networks infrastructures (SAHARA) ------------------------------------------------------------------------ 1.3 Abstract del Programma di Ricerca Testo italiano Il panorama delle infrastrutture di comunicazione fa prevedere a breve la disponibilita' di infrastrutture di trasmissione e comunicazione di diversi tipi e variamente integrate, su cui realizzare applicazioni e servizi a accesso eterogeneo (HASA, da Heterogeneous Access Software Applications). Gli utenti di HASA, generalmente mobili, utilizzano dispositivi di accesso di varia natura (PC, PDA, telefoni cellulari, communicators, etc.) e possono accettare una qualita` di servizio (QoS) variabile a seconda del luogo, del momento, del dispositivo in uso, ecc. La natura dell'infrastruttura di rete ad accesso eterogeneo (HANI, da Heterogeneous Access Networks Infrastructure) utilizzata dalle HASA, ne rende particolarmente problematica la progettazione e realizzazione, dato che le HASA devono funzionare in condizioni di instabilita' di connessione, comunicazione e trasmissione, mantenendo comunque un'adeguata QoS. Altro elemento di complessita' e' la necessita` di "consapevolezza del contesto": l'adeguatezza del servizio dipende dinamicamente dal contesto operativo. Il progetto Sahara ha l'ottica dell'applicazione, ossia delle metodologie di progettazione e convalida delle HASA. I correnti paradigmi di progettazione non tengono conto di scenari di esecuzione molto diversi tra loro, che possono portare a QoS piu' o meno degradate a seconda dei fattori visti sopra. Date le tendenze generali dell'Ingegneria del Software e le esperienze maturate su tematiche affini, i proponenti individuano nelle Architetture Software (AS) il migliore livello di astrazione per proporre e convalidare tecniche e metodi di specifica, progettazione, riuso, verifica e convalida delle HASA. In particolare si intendono trattare caratteristiche "qualitative" come distribuzione, localita', capacita' di mantenere la connessione, disponibilita' del servizio, risparmio dell'energia consumata, ecc. Il progetto, come primo obiettivo vuol valutare il numero di livelli necessari a caratterizzare al meglio i modelli architetturali. Attualmente, il nostro schema di riferimento vede due livelli tra HASA e HANI, di cui uno vicino alla realta' fisica, il "Middleware", e uno vicino all'applicazione, l'"Architettura Software". Il livello identificato come Middleware si deve basare sui risultati delle attivita' di standardizzazione delle interfacce per HANI, in particolare per le infrastrutture 3G (reti di terza generazione). A livello applicativo, il problema e` di stabilire quali caratteristiche della rete si vogliono poter vedere, e quali elaborazioni di tali caratteristiche si vogliono poter utilizzare. Il progetto si propone di fornire una caratterizzazione dei livelli di astrazione architetturale necessari allo sviluppo di HASA, e di proporre strumenti di analisi e di verifica di loro proprieta' funzionali e di QoS. Obiettivi intermedi sono l'identificazione delle classi di domini applicativi per HASA e i diversi requisiti che esse pongono sulle AS, l'identificazione dei requisiti che una HANI induce sul Middleware e un mapping accettabile a livello applicativo, che garantisca il livello di "consapevolezza del contesto" richiesto dalle HASA. Il progetto, organizzato su due fasi, si articola in quattro temi: Notazioni e tecniche architetturali rigorose, Caratterizzazione di AS per classi di HASA, Middleware per HASA e Analisi e convalida delle architetture. Nella prima fase si avra` trasferimento di conoscenze consolidamento delle sinergie culturali, la definizione di AS per HASA significative e delle caratteristiche salienti del Middleware, e la definizione di un mapping tra le AS individuate ed il Middleware. La seconda fase definira` un insieme di proprieta' e strumenti da integrare in un coerente paradigma di sviluppo di HASA. I principali risultati previsti sono la classificazione e descrizione delle AS per HASA, le nozioni di QoS e di proprieta` legate alla consapevolezza del contesto per HASA, la realizzazione del middleware. Testo inglese The current panorama of the communication infrastructures let us foresee that several kinds of varioulsy integrated transmission and communication infrastructures will be available in the near future. In such a scenario, it will be possible to implement heterogeneous access software applications (HASA), whose users are likely to be mobile, to employ access devices of various kinds (PCs, PDAs, cellular phones, communicators, etc.), and to be willing to accept varying QoS according to the place, the time, the device in use, etc. The nature itself of the network infrastructure (HANI, from heterogeneous access network infrastructure) that these applications will be using, makes their design and implementation particularly challanging: they must be able to run when connections, commnunicatons, and transmission are instable, still providing adequate QoS. The fact that the application must be "context-aware", i.e. that the service can be more or less adequate depending on the current context, adds to the complexity of HASAs. The SAHARA project takes an application point of view, that is we are concerned with the design and validation methodologies for HASAs. The current development paradigms don't cater with execution contexts that can be very varied, and lead to more or less degraded QoS, according to the factors seen above. According to general Software Engineering tendencies, and to previous experiences in research projects on similar topics, we identify in the Software Architecture (SA) the best abstraction level to introduce and validate techniques and methods for HASA specification, design, verification and validation. We are interested in dealing with quality attributes like distribution, locality, ability to sustain a connection, service availablity, energy saving, etc. The first objective of the SAHARA project is to assess the number of levels needed for the best characterization of the architectural models. Our current reference schema sees two levels between HASA and HANI: one, called "Middleware", near to the physical infrastructure, another, called "Software Architecture", near to the application. There are many ongoing activities on the standardization of HANI interfaces, especially for 3G (third generation) infrastructures. The main open point at the application level is which network characteristics the application has to see, and which elaborations of the same characteristics it might be interested in. The global objective of the project is to provide a characterization of the architectural abstraction levels needed to properly develop HASAs, together with some proposals of analysis and verification tools, tuned to the functional and QoS properties of interest. Intermediate objectives are to identify interesting classes of HASA domains, and the diverse requirements they induce on the SAs, to identify the requirements that a HANI induces on the Middleware, and a mapping from the middleware and the SA that delivers the context-awareness that the applications require. The project has two phases and four themes: rigorous notations and techniques for HASA, SA characterization for classes of HASA, Middleware, and Analysis and validation of HASA architectural descriptions. Phase one, besides allowing knowledge transfer, will deliver the SA definitions of relevant HASA classes, the definition of the main characteristics of the Middleware, and of the mapping from the SAs to the middleware. Phase two will deliver the definition of a set of properties and tools to be integrated in a coherent development paradigm for HASA. The main foreseen results are the classification and description of HASA SAs, the notions of QoS and the properties related to context-awareness, the analysis tools, and the middleware implementation. ------------------------------------------------------------------------ 1.4 Durata del Programma di Ricerca: 24 mesi ------------------------------------------------------------------------ 1.5 Settori scientifico-disciplinari interessati dal Programma di Ricerca * INF/01 - INFORMATICA ------------------------------------------------------------------------ 1.6 Parole chiave Testo italiano ARCHITETTURE SOFTWARE ; ANALISI E TESTING BASATO SU ARCHITETTURE ; PROGRAMMAZIONE MOBILE ; SISTEMI DISTRIBUITI ; ANALISI DI PROGRAMMI ; LINGUAGGI DI COORDINAMENTO ; SPECIFICA DEL SOFTWARE ; ANALISI BASATA SU COMPONENTI Testo inglese COMPONENT-BASED ANALYSIS ; PROGRAM ANALYSIS ; MOBILE PROGRAMMING ; SOFTWARE SPECIFICATION ; ARCHITECTURE-BASED TESTING AND ANALYSIS ; SOFTWARE ARCHITECTURES ; COORDINATION LANGUAGES ; DISTRIBUTED SYSTEMS ------------------------------------------------------------------------ 1.7 Coordinatore Scientifico del Programma di Ricerca ------------------------------------------------------------------------ 1.8 Curriculum scientifico Testo italiano Paola Inverardi e' professore ordinario presso la Universita' dell'Aquila. Precedentemente ha lavorato presso l'IEI-CNR di Pisa e presso il centro di ricerche dell'Olivetti a Pisa. Paola Inverardi si occupa di applicazioni di tecniche formali allo sviluppo del software. Negli ultimi anni i suoi interessi di ricerca si sono principalmente rivolti alla area delle architetture software. In particolare ha proposto l'utilizzo di un linguaggio di specifica basato sulla riscrittura per la specifica di architetture software, la Chemical Abstract Machine, gia' nota in letteratura come modello di specifica generale. Nei suoi lavori si e' occupata di analisi delle specifiche architetturale, sia di tipo comportamentale che quantitativo. Su questi temi collabora attivamente con una serie di imprese italiane e straniere. Recentemente si sta occupando di progettazione di applicazioni mobili con particolare riferimento al protocollo WAP. E' membro di comitati di programma di workshop e conferenze che si occupano di architetture software e di ingegneria del software tra cui IWSSD'97, IWSSD'98, ICSE'97, ISAW'98, COORDINATION'99, COORDINATION2000, WOSP98 e WOSP2000, IFIP WICSA1-99 e 2001, FSE-ESEC 99, ICSE 2000, ICSE2002. E' stata co-chair di un workshop congiunto CNR-NSF, tenutosi a Luglio 98, su "Il ruolo delle Architetture Software nella analisi e nel testing", ed al quale hanno partecipato i piu' rappresentativi esponenti europei e statunitensi del settore delle architetture software. E' stata co-chair del workshop internazionale IWSSD 2000, tenutosi a S. Diego. Sara' general chair e co-program chair del workshop WOSP02 che si terra' a Luglio nel 2002 e sara' program chair della conferenza FSE/ESEC del 2003. E' autore di oltre 60 pubblicazioni su riviste o atti di convegni internazionali. Testo inglese Paola Inverardi's main research area is in the application of formal methods to software development. In recent year her research interests mainly concentrated in the field of software architectures. She has proposed the use of a rewriting-based specification language, already known in the literature, the Chemical Abstract Machine, to describe software architectures. In her papers she has addressed the verification and analysis of software architecture properties, both behavioral and quantitative. On this topics she actively collaborates with several national and international companies. Recently she is working on the design and development of mobile applications with specific reference to the WAP protocol. She participated and participates to several program committee of workshop and conferences on software architectures and software engineering among which IWSSD'97, IWSSD'98, IWSSD2000, ICSE'97, ISAW'98, COORDINATION'99, IFIP WICSA1-99, FSE_ESEC99, ICSE2000, COORDINATION 2000, WICSA 2001, WOSP 98 and WOSP2000, ICSE 2002. She is co-chair of IWSSD 2000 and she has been co-chair of a joint CNR-NSF workshop on "The Role of Software Architectures in analysis and testing", held July 98, with the participation of the most prominent European and USA researchers in the field of software architectures. She will be general chair e co-program chair of the WOSP02 workshop in July 2002 and she will be program chair of the FSE/ESEC conference in 2003. She is the author of over sixty publications in international journals and conference proceedings. ------------------------------------------------------------------------ 1.9 Pubblicazioni scientifiche pi significative del Coordinatore del Programma di Ricerca 1. INVERARDI P., A. L. WOLF. (1995). Formal Specifications and Analysis of Software Architectures Using the Chemical Abstract Machine Model. IEEE TRANSACTION ON SOFTWARE ENGINEERING. vol. 21/4, pp. 373-386. 2. INVERARDI P., D. YANKELEVICH, A.L. WOLF. (2000). Static Checking of System Behaviors Using Derived Component Assumptions. ACM TRANSACTION ON SOFTWARE ENGINEERING AND METHODOLOGY. vol. 9. 3. F. AQUILANI, S. BALSAMO, INVERARDI P. (2001). Performance Analysis at the Software Architectural Design Level. PERFORMANCE EVALUATION. apparira'. 4. C. COLAFIGLI, INVERARDI P., R. MATRICCIANI. (2001). Infoparco: An experience in designing an information system accessible through WEB and WAP interfaces. HICCS 34. versione estesa sottomessa per pubblicazione su rivista. 5. A. BERTOLINO, INVERARDI P., H. MUCCINI. (2001). An Explorative Journey from Architectural Tests Definition downto Code Tests Execution. ACM International Conference on Software Engineering. ------------------------------------------------------------------------ 1.10 Elenco delle Unita' di Ricerca N Responsabile Qualifica Settore Universit Dipart./Istituto Mesi scientifico disc. uomo INFORMATICA E 1.ASTESIANO Prof. SCIENZE EGIDIO ordinario K05B GENOVA DELL'INFORMAZIONE 77 2.BALSAMO Prof. MARIA ordinario K05B VENEZIA INFORMATICA 90 SIMONETTA 3.CANFORA Prof. SANNIO di SANNIO - BENEVENTO 134 GERARDO associato K05A BENEVENTO 4.CIANCARINI Prof. SCIENZE 198 PAOLO ordinario K05B BOLOGNA DELL'INFORMAZIONE 5.GHEZZI CARLO Prof. POLITECNICO ELETTRONICA E ordinario K05A MILANO INFORMAZIONE 87 6.GRASSI Prof. ROMA "Tor INFORMATICA, 124 VINCENZO associato K05A Vergata" SISTEMI E PRODUZIONE 7.INVERARDI Prof. MATEMATICA PURA E 250 PAOLA ordinario K05B L'AQUILA APPLICATA 8.MONTANGERO Prof. 100 CARLO ordinario K05B PISA INFORMATICA ------------------------------------------------------------------------ 1.11 Mesi uomo complessivi dedicati al programma numero mesi uomo Personale universitario dell'Universit sede 585 dell'Unit di Ricerca 34 (ore: 80145) (docenti) Personale universitario dell'Universit sede 1 6 dell'Unit di Ricerca (altri) (ore: 825) Personale universitario di 14 altre Universit (docenti) 1 (ore: 1925) Personale universitario di altre Universit (altri) 0 0 Titolari di assegni di ricerca 6 87 (ore: 11919) Titolari di borse dottorato e 296 post-dottorato 16 (ore: 40700) Personale a contratto 5 58 (ore: 7975) Personale extrauniversitario 1 14 (ore: 1925) Totale 64 1060 (ore: 145414) ------------------------------------------------------------------------ Parte: II 2.1 Obiettivo del Programma di Ricerca Testo italiano Il panorama delle infrastrutture di comunicazione fa prevedere a breve la disponibilita' di tipi di infrastrutture di trasmissione e comunicazione, variamente integrate. In tale scenario sara' possibile realizzare applicazioni e servizi a accesso eterogeneo (HASA, da Heterogeneous Access Software Applications), i cui utenti, potenzialmente mobili, utilizzano dispositivi di accesso di varia natura (PC, PDA, telefoni cellulari, communicators, etc.) e sono disposti ad accettare una qualita` di servizio (QoS) variabile a seconda del luogo, del momento, del dispositivo in uso, ecc. La natura dell'infrastruttura di rete ad accesso eterogeneo (HANI, da Heterogeneous Access Networks Infrastructure) utilizzata da queste applicazioni rende particolarmente problematica la loro progettazione e realizzazione, dato che devono essere in grado di funzionare in condizioni di instabilita' di connessione, comunicazione e trasmissione, mantenendo comunque un'adeguata QoS. Altro elemento di complessita' e' la necessita` di "consapevolezza del contesto": l'adeguatezza del servizio dipende dinamicamente dal contesto operativo. Il progetto Sahara ha l'ottica dell'applicazione, ossia delle metodologie di progettazione e convalida delle HASA. I correnti paradigmi di progettazione non tengono conto, nelle varie fasi, di scenari di esecuzione molto diversi tra loro, che possono portare a QoS piu' o meno degradate a seconda dei fattori visti sopra. Il panorama internazionale sia della ricerca accademica sia di quella orientata al mercato delle aziende di telecomunicazioni e software e' molto carente in questa direzione. I proponenti, in base alle tendenze generali dell'Ingegneria del Software e a esperienze maturate in progetti su tematiche affini, individuano nelle Architetture Software (AS) il migliore livello di astrazione per proporre e convalidare tecniche e metodi di specifica, progettazione, verifica e convalida delle HASA. Queste architetture devono permettere la descrizione e l'analisi, anche quantitativa, dei metodi di comunicazione, interazione e coordinamento fra le componenti di sistemi distribuiti in ambienti molto instabili, per la presenza di mobilita' fisica e logica in una infrastruttura eterogenea. Allo stesso tempo, esse devono offrire la base per una realizzazione che sia coerente e convalidabile rispetto alla specifica architettonica e rispetto ai requisiti di QoS. La caratteristiche "qualitative" che si intendono trattare sono relative a distribuzione e localita', capacita' di mantenere la connessione, disponibilita' del servizio, risparmio dell'energia consumata, ecc. La complessita' del progetto di HASA accentua la necessita' di strumenti di supporto del progettista, per valutare, fin dalle prime fasi di progetto, l'impatto di differenti alternative sulla qualita' dell'applicazione. Ulteriori elementi di complessita' vengono dalle spinte di mercato ad offrire in tempi molto rapidi una grande varieta' di applicazioni e servizi per HANI, il che richiede di basarsi su componenti, sia "legacy" sia "off the shelf". Un primo obiettivo del progetto SAHARA e` la valutazione del numero di livelli necessari a caratterizzare al meglio i modelli architetturali. Attualmente, il nostro schema di riferimento vede due livelli tra HASA e HANI, di cui uno vicino alla realta' fisica, il "Middleware", e uno vicino all'applicazione, l'"Architettura Software". Allo stato attuale c'e' molta attivita' per standardizzare le interfacce per HANI, in particolare per le infrastrutture 3G (reti di terza generazione - http://www.parlay.org, http://www.3gpp.org): si vuol definire un livello di interfaccia alla rete per le applicazioni, che omogeneizzi i differenti tipi di comunicazione e trasmissione, e che preveda la definizione anche di servizi accessori da rendere disponibili allo strato applicativo. Questo strato si offre come interfaccia al livello da noi identificato come middleware. Resta da stabilire quali caratteristiche della rete si vogliono rendere visibili alle applicazioni, e quali elaborazioni di tali caratteristiche l'applicazione puo' voler utilizzare. L'obiettivo complessivo del progetto e' quello di fornire una caratterizzazione dei livelli di astrazione architetturali necessari allo sviluppo di HASA, corredati dalla proposta di strumenti di analisi e di verifica di proprieta' funzionali e di QoS delle applicazioni. Un obiettivo intermedio e' l'identificazione delle classi di domini applicativi per HASA, e i diversi requisiti che esse pongono sulle AS. Contestualmente studieremo le caratteristiche delle HANI, anche analizzando le proposte di piattaforme 3G esistenti, per determinare i requisiti che una HANI induce sul Middleware. I due livelli saranno poi confrontati per definire un mapping accettabile a livello applicativo, che garantisca il livello di "consapevolezza del contesto" richiesto dalle HASA. Obiettivo piu' generale e' l'avanzamento della conoscenza nello sviluppo di HASA in termini sia metodologici, nella nozione classica dell'ingegneria del software, sia di merito, per definire appropriate nozioni di QoS. In dettaglio il progetto si pone quattro obiettivi tematici. TEMA1. Definizione di notazioni e tecniche rigorose per descrizioni di AS. Si vogliono descrivere sia i vari livelli architetturali, incluso il middleware, sia le HASA. Le notazioni devono permettere la definizione di tutte le proprieta' di contesto necessarie e permetterne l'analisi e la verifica. Le proprieta', di tipo comportamentale e qualitativo, sono specificate sulla descrizione statica e dinamica delle astrazioni architetturali. TEMA2. AS di supporto alla realizzazione di applicazioni HASA. Questo tema riguarda le classi di AS caratterizzanti i vari tipi di HASA. Un problema e` se le singole AS possono essere viste come esemplari di un unico generico stile, dato che le architetture devono permettere la specifica di tutte le proprieta' di interesse. Inoltre si devono definire opportune relazioni tra i vari livelli architetturali e, per l'integrazione di sistemi legacy, metodi di analisi di software esistente per ricostruirne viste architetturali compatibili con la caratterizzazione del progetto. TEMA3. Middleware per HASA. Progettare un middleware che fornisca i meccanismi abilitanti per rendere l'applicazione cosciente del contesto in cui viene eseguita e per favorirne l'adattamento. Il middleware fornisce all'applicazione informazioni astratte sulla QoS offerta da rete e dispositivi. Il tema copre anche metodi e tecnologie di wrapping per l'integrazione in HASA di componenti legacy. TEMA4. Analisi e convalida delle descrizioni architetturali per HASA. Verranno definite le proprieta' (adeguatezza delle risorse disponibili, riusabilita' di componenti legacy, ecc.), le tecniche di analisi (prove logiche e dimostrazioni semi-automatiche, modelli analitici di valutazione, ecc.) e di convalida (definizione di casi di test, proprieta' di wrappers, ecc.), i metodi e strumenti di reverse-engineering per mappare le applicazioni legacy sulle AS definite. Il progetto si pone come obiettivo metodologico la cooperazione di competenze diverse e complementari, indispensabili per ottenere risultati significativi in un'area in cui devono coesistere ed interagire metodi e strumenti specifici di diversi settori dell'informatica. Le unita' che partecipano al progetto rappresentano preminenti realta' di ricerca nazionali, con ampi riconoscimenti internazionali. Il progetto e' organizzato in due fasi. Prima fase: trasferimento di conoscenze e consolidamento delle sinergie culturali tra le unita', definizione di AS per HASA significative, delle caratteristiche salienti del middleware e di un mapping tra le AS individuate ed il middleware. Seconda fase: sulla base della prima, definizione di un insieme di proprieta' e strumenti da integrare in un coerente paradigma di sviluppo di software per HASA. Testo inglese The current panorama of the communication infrastructures let us foresee that several kinds of varioulsy integrated transmission and communication infrastructures will be available in the near future. In such a scenario, it will be possible to implement heterogeneous access software applications (HASA), whose users are likely to be mobile, to employ access devices of various kinds (PCs, PDAs, cellular phones, communicators, etc.), and to be willing to accept varying QoS according to the place, the time, the device in use, etc. The nature itself of the network infrastructure (HANI, from heterogeneous access network infrastructure) that these applications will be using, makes their design and implementation particularly challanging: they must be able to run when connections, commnunicatons, and transmission are instable, still providing adequate QoS. The fact that the application must be context-aware, i.e. that the service can be more or less adequate depending on the current context, adds to the complexity of HASAs. The SAHARA project takes an applicative point of view, that is we are concerned with the design and validation methodologies for HASAs. The current development paradigms don't cater with execution contexts that can be very varied, and lead to more or less degraded QoS, according to the factors seen above. The international panorama of research, both in the academia and in the more market oriented research centers of the software and telecommunication companies, is lacking in this directions. A notable wider spectrum current approach is described at http://www.cs.cmu.edu/~aura/. According to general Software Engineering tendencies, and to previous experiences in research projects on similar topics, we identify in the Software Architecture (SA) the best abstraction level to introduce and validate techniques and methods for HASA specification, design, verification and validation. These architectures must support the description and the quantitative analysis of the communications, interactions and coordinations among the components of distributes systems in very unstable environments, due to logical and physical mobility in a heterogeneous infrastructure. Besides, they must be the base for a coherent implementation, which one can validate against both the architectural specification and the QoS requirements. It must be possible to deal with quality attributes like distribution, locality, ability to sustain a connection, service availablity, energy saving, etc. The complexity of the design of a HASA emphasizes the need of support tools, to help the designer in assessing, since the early development phases, how different choices will impact on the application quality. The market push for quick availability of a great variety of application and servicies on HANI adds further complexity, because of the need to integrate off-the-shelf and legacy components. The first objective of the SAHARA project is to assess the number of levels needed for the best characterization of the architectural models. Our current reference schema sees two levels between HASA and HANI: one, called "Middleware", near to the physical infrastructure, another, called "Software Architecture", near to the application. There are many ongoing activities on the standardization of HANI interfaces, especially for 3G (third generation) infrastructures (see for instance http://www.parlay.org, http://www.3gpp.org.) The goal is to define an application interface of the network, to make the different kinds of communication and transmission as homogeneous as possible, and to provide also the definition of general purpose services to the application layer. This interface is precisely the support to the layer that we identify as middleware. The main open point is which network characteristics the application has to see, and which elaborations of the same characteristics it might be interested in. The global objective of the project is to provide a characterization of the architectural abstraction levels needed to properly develop HASAs, together with some proposals of analysis and verification tools, tuned to the functional and QoS properties of interest. As an intermediate objective, we plan to identify interesting classes of HASA domains, and the diverse requirements they induce on the SAs. At the same time, we will study the characteristics of HANIs, also looking at the current 3G platform proposals, to identify the requirements that a HANI induces on the Middleware. The comparison of the two levels will lead to a mapping, which will be acceptable at the application level if it will deliver the context-awareness that the applications require. A general target of the project is the advancement of knowledge in the development of HASAs, not only methodologically, in the general sense of Software Engineering, but also introducing appropriate QoS notions. In details, the project has four themes. THEME1. Definition of rigorous notations and techniques for HASA. The goal is to describe both the HASAs and the various architectural levels, Middleware included. The notations must permit the definition of all the contextual properties of interest, and their analysis and verification. The properties, both behavioural and qualitative, are specified on the abstract static and dynamic architectural descriptions. THEME2. SA characterization for classes of HASA. This theme covers the SA classes that characterize the various HASA domains. A problem is: can any SA be viewed as an instance of a single style? The point is that each architecture must permit the expression of all the properties of interest. Besides, we must identify the relevant relations between the different architectural levels, and, to be able to integrate legacy systems, also the methods to extract architectural views from existing software, which are compatible with our characterizations. THEME3. Middleware for HASA. The goal is to implement a middleware that provides the mechanisms to abilitate the application context-awareness, and to support its adaptation to context changes. That is, the middleware offers an abstract view of the QoS offered by the network and its services. Besides, this theme deals with the wrapping techniques to integrate legacy components into HASAs. THEME4. Analysis and validation of HASA architectural descriptions. We will define the properties of interest (like the degree to which resources are available or legacy components can be reused), the analysis techniques (like logical, semi-automatic proofs and evaluation models), the validation techniques (like test cases definitions and wrappers properties), and the reverse-engineering methods and tools to map legacy applications on the identified SAs. The project assumes the methodological objective of making different complementary competences cooperate, since they are necessary to reach significant results in an area that requires the coexistance and interactions of methods and approaches which belongs to diverse sectors of Computer Science. The partners of the project represent relevant national research centers, and are internationally widely recognized. There are two phases in the project. Phase one: knowledge transfer, definition of SAs for relevant HASA classes, definition of the main characteristics of the Middleware, and of the mapping from the SAs to the middleware. Phase two: definition of a set of properties and tools to be integrated in a coherent development paradigm for HASA. ------------------------------------------------------------------------ 2.2 Base di partenza scientifica nazionale o internazionale Testo italiano TEMA1. Definizione di notazioni e tecniche architetturali rigorose per HASA. Il ruolo della AS nello sviluppo di applicazioni software di grandi dimensioni oramai ampiamente riconosciuto sia nel mondo accademico sia in quello industriale. Negli ultimi anni sono stati proposti diversi linguaggi di descrizione architetturale (ADL, Architecture Description Language), da linguaggi pensati per la descrizione architetturale (MT00, BHH99), a notazioni piu` vicine al progetto, come UML (JBR99, GAK00, HNS00, etc.). Tuttavia non finora emerso un consenso a livello notazionale, sebbene si stiano sempre pi consolidando approcci che tentano di integrare concetti architetturali in notazioni sempre pi diffuse nella pratica dello sviluppo software, come UML. Riferendosi a UML, molti dei concetti emersi nelle AS non vi trovano adeguata corrispondenza (GAK00). Le soluzioni che stanno emergendo sono tipiche di UML, cio la definizione di profili ed il cosiddetto metamodelling. Un profilo fornisce dei meccanismi per specializzare il metamodello di riferimento in domini specifici, ad esempio per trattare sistemi in tempo reale o business objects (OMG99); per un tentativo relativo ad AS vedasi (MKS00). Inoltre stanno emergendo tecniche di "metamodelling", sempre visuali e OO, sia per definire i profili in modo appropriato, sia per definire la nozione stessa di profilo; recentemente stato proposto all'OMG un approccio metamodelling, che utilizza ML (un kernel minimale di UML) per la definizione di tutto UML, sintassi e semantica inclusa (COO00). Queste tecniche si possono complementare con tecniche basate su sistemi di transizione etichettati per modellare gli aspetti dinamici di UML, individuandone punti problematici (RAC00). Le stesse tecniche permettono di definire i cosiddetti UML systems nell'ambito di un approccio multi-viste alla semantica di UML (RCA01). Rimane carente la possibilita` di esprimere behaviours di processi. Le attuali tecniche sono limitate al linguaggio naturale oppure ad OCL (Object Constraint Language), una notazione formale adottata quasi come standard aggiunto a UML per esprimere propriet su oggetti (ma non behaviours, eccetto che nella forma pre/post-conditions). Per quanto riguarda gli ADL, ci sono proposte che tentano di modellare gli aspetti di mobilit individuando paradigmi per la progettazione di AS dove i concetti di locazione dei componenti e di mobilit verso nuove locazioni sono espliciti, come accade nei paradigmi di codice su domanda (COD), valutazione remota (REV), agenti mobili (MA) (FPV98). Quest'area di ricerca ha avuto un riflesso anche nei linguaggi, con proposte dove la locazione e la mobilit dei componenti sono trattate come concetti di "prima classe" (CG98, RM98, TSE98). Analogamente aperta l'area di ricerca che cerca di integrare informazioni quantitative allinterno delle descrizioni architetturali. Gli approcci in questo settore vanno dalla definizione di algebre di processo opportunamente integrate con informazioni quantitative (BCD00) all'utilizzo di tecniche di annotazione dei documenti progettuali, tipicamente inseriti in un processo tipo UML (CM00, P00). La problematica di mobilit ed instabilit della infrastruttura affrontata in lavori molto recenti (GC00). TEMA2. Caratterizzazione di AS per classi di HASA . Lo studio di AS per applicazioni HASA molto preliminare data la innovativit e la disponibilit solo parziale di infrastrutture HANI. Ciononostante ci sono classi di applicazioni le cui problematiche architetturali possono costituire una buona base di partenza per lo studio di AS per HASA. Una prima tipologia di applicazioni quella che sta emergendo nell'ambito delle nuove infrastrutture per Internet e pi specificamente per il Web. In particolare connessa con l'idea di "software come servizio". L'esempio principale la recente iniziativa .NET di Microsoft. L'idea nasce in parte dall'evoluzione di RPC prima e CORBA/DCOM poi, in cui sono state sviluppate infrastrutture e meccanismi per accedere a funzionalit remote al sistema in cui si opera. Nuovi protocolli di interoperabilita` per componenti, quali SOAP, basati su HTTP, e XML sono stati adottati per superare i problemi di eterogeneit e bassa affidabilit di Internet. Un aspetto rilevante dello stato dell'arte concerne l'utilizzo di linguaggi di markup come espressione di relazione complesse tra dati. I linguaggi di markup permettono una logica organizzativa basata sui formati, invece che sulle procedure, e ben si applicano a problemi di ingegneria del software, editoria elettronica, tecnologie di rete. Le tecnologie XML, XSLT e XLink vengono utilizzate per realizzare un ambiente integrato ove implementare funzionalit ipertestuali avanzate per il supporto di notazioni specializzate, computazioni distribuite, interfacce utente sofisticate, etc. Nello stesso ambito si possono collocare le esperienze di progettazione di applicazioni basate su protocolli mobili quali il WAP, che devono tenere conto della limitatezza dei dispositivi di accesso e della bassa affidabilita` delle connessioni (Man00,CIM01), ma al contempo possono richiedere alta qualit di servizio nella gestione di particolari classi di applicazioni, quali quelle di m-commerce, che richiedono transazionalit e sicurezza. In questi casi le tecniche utilizzate nell'ambito del tradizionale e-commerce e basate sul paradigma client-server non possono essere applicate e devono essere proposte nuove tipologie architetturali, in grado di sfruttare al meglio quello che le l'infrastruttura di rete mette a disposizione (VV00, ON01). Una altra tipologia di architettura quella suggerita da applicazioni che sono diventate popolari nel mondo Internet, come Napster (http://www.napster.com), Gnutella (http://www.gnutella.org) e Freenet (http://freenet.sourceforge.net). In queste applicazioni si passa da un modello client server ad uno peer to peer, dove le applicazioni distribuite sono costituite da utenti che trasparentemente condividono parte delle loro informazioni che risiedono su host locale. Questo modello architetturale potrebbe ben adattarsi ad applicazioni che devono basarsi su una infrastruttura di rete ad-hoc, dove l'interazione peer to peer sembra essere la pi naturale. Ulteriori elementi di riflessione possono venire dalle architetture di supporto alla migrazione di sistemi legacy. Negli anni passati si assistito alla migrazione da sistemi batch a sistemi interattivi, da architetture monolitiche ad architetture client-server, da modelli procedurali a modelli ad oggetti, da interfacce a caratteri ad interfacce grafiche. Gli strumenti metodologici e tecnologici creati nei suddetti processi di migrazione possono essere una buona base di partenza per affrontare il problema della migrazione verso HANI. Un fattore chiave quello di definire il modello architetturale di riferimento da poter utilizzare nel definire metodi e strumenti per la individuazione di componenti e connettori nel codice sorgente da re-ingegnerizzare. Nell'ambito della reingegnerizzazione di codice procedurale verso architetture object-oriented, sono stati definiti numerosi approcci che si differenziano per la grana degli oggetti prodotti, il livello di persistenza, la tipologia di linguaggio di programmazione a cui sono applicabili, ed il grado di automazione (CCM96, L97, GK00 ). Significativi sono i risultati ottenuti nella migrazione da architetture monolitiche ad architetture client-server. In tale settore ci sono contributi relativi sia alla pianificazione, organizzazione e controllo del processo di migrazione (BS95, B96, S99) sia agli aspetti tecnici di individuazione delle componenti client e server (SN94, CCD00) e di reingegnerizzazione delle stesse (AV97). Pi recentemente un ruolo importante giocato dai metodi e strumenti di reverse engineering a livello architetturale (FAT99, HRY95, YHC97). TEMA3. Middleware per HASA. Negli ultimi anni il middleware e' diventato una componente tecnologica che riveste crescente interesse. Dal workshop OM 2001 (http://www.cs.wics.edu/~bodik/om2001/cfp.html): "Middleware software is an intelligent plumbing that connects the client side of a distributed application with a database or a web server. The term middleware is intended to extend far beyond the current industrial technologies for e-commerce applications. Roughly, it is meant to include all systems software that provides enabling services needed by a distributed application, for example: connectivity software that allows multiple processes interact across a network, Java virtual machines that execute the communicating software components, and operating systems and run-time libraries that schedule parallel execution threads." Middleware e' quindi linsieme di servizi che vengono messi a disposizione del progettista di applicazioni per facilitarne la progettazione in specifici domini. Esempi di middleware sono le architetture e piattaforme per programmazione per componenti quali RM-ODP, CORBA, RMI e DCOM. E' di critica importanza il tema del middleware in ambienti di reti eterogenei: "The focus of Middleware 2001 is on the design, implementation, deployment and evaluation of distributed systems platforms and architectures for future networked environments. Of particular interest is the experience in environments which may include public, private and mobile networks, overlaid wired and wireless technologies, IPv6 and IP multicast, multimedia and real-time information and an increasing volume of WWW and Java traffic." Egualmente centrale e' il Middleware for Mobile Computing "The software infrastructure to support mobile applications is becoming critically important to the next horizon in computing." (http://www.labs.agilent.com/middleware2001/). In letteratura esistono varie tecnologie per i sistemi distribuiti, che possono essere adattate allo scenario HANI. Nei linguaggi di programmazione, Java permette di progettare sistemi software basati sul paradigma a codice mobile. Questo consente a un'applicazione distribuita di rilocare dinamicamente alcuni dei suoi componenti sui nodi della rete. Cio' rende possibile ottenere maggiore flessibilita' nell'uso delle risorse, limitare l'uso dei canali di comunicazione, o supportare modalit di computazione disconnesse. L'aspetto della mobilita' di codice particolarmente rilevante nelle HANI poiche' i canali wireless sono tipicamente rumorosi e a bassa capacita', e l'evento disconnessione caratteristico di questo dominio. Nei middleware T-Space(LMW99), JavaSpace(SUN99) e LIME(MPR99) la comunicazione tra componenti avviene tramite uno spazio virtuale condiviso. I componenti possono accedere sia in scrittura per depositare informazioni (tuple), che in consultazione. Il modello alla base di questi middleware, Linda (CG89), e' stato impiegato con successo nella computazione parallela ed e' stato esteso in vari modi per supportare la coordinazione fra i componenti di un sistema distribuito. Esso permette di realizzare un disaccoppiamento tra le parti coinvolte nella comunicazione, proprieta' desiderabile in HANI dove la possibilita' che alcune parti della rete siano disconnesse e' alta. Nei middleware ad eventi (CNF01) i componenti di un sistema software interagiscono attraverso la generazione e la ricezione di eventi. Un evento generato da un componente viene pubblicato su un canale o dispatcher che provvede a ridistribuirlo a tutti i componenti interessati a riceverlo. Il canale agisce da intermediario tra la sorgente ed il destinatario di un evento consentendo un disaccoppiamento tra queste due tipologie di componenti. Alcune proposte combinano i meccanismi a eventi e/o gli spazi di tuple nel contesto del modello object-oriented, dando vita a middleware object-oriented distribuiti. E' questo il caso di CORBA (OMG98), che fornisce un servizio di distribuzione di eventi, e della piattaforma Jini(E00), che integra, in un middleware basato interamente sul linguaggio Java, object-orientation, eventi, transazioni, e spazi di tuple. Tecniche di supporto alla integrazione di componenti legacy, come il wrapping, sono state elemento vincente della popolarita' di middleware come CORBA. La tecnologia di wrapping ha giocato un ruolo fondamentale ai fini della migrazione di sistemi legacy verso infrastrutture di rete (AC96, M94, S96, S00). Un wrapper uno strato di software che racchiude una porzione di codice o un'intera applicazione legacy. L'interfaccia di cui il wrapper e' dotato consente le interazioni con le applicazioni esterne tramite meccanismi di scambio di messaggi. Il wrapping di un sistema legacy puo' avvenire a vari livelli: possono essere oggetto di wrapping intere applicazioni legacy, solo alcune componenti di interfaccia dedicate all'inserimento e alla presentazione di dati, il database che gestisce le operazioni sui dati, o alcuni servizi applicativi (OMG98, CCD99a, CCD99c, ACC01). TEMA4. Analisi e convalida di architetture per HASA. La descrizione delle AS e' tradizionalmente basata su formalismi grafici per la parte statica (tipico il caso di UML) e su vari formalismi, sia di tipo operazionale, come la Chemical Abstract Machine [IW95] o algebre di processo [AG97, GMC99], sia di tipo dichiarativo, tipicamente logiche temporali [WF98]. Il tipo di analisi condotte finora e' stato principalmente di tipo funzionale, e solo recentemente si sono iniziati ad affrontare i problemi posti dalla mobilita`, sia fisica che logica [RPM00, CFM00, PMR01], e quelli posti dalle caratteristiche qualitative e non solo funzionali delle applicazioni, e solo relativamente alle prestazioni. In relazione alla fase di validazione dei sistemi recentemente sono stati proposti degli approcci che utilizzano le informazioni architetturali, con particolare riferimento al testing di integrazione {Har00,BIM01}. Dal punto di vista funzionale sono stati utilizzati strumenti noti nella letteratura scientifica per l'analisi, la verifica e la convalida dei sistemi. Tra quelli piu' utilizzati nellambito AS ci sono le tecniche di riscrittura {HIM00,PW00} (di termini o grafi), le logiche temporali e modali {KM99,SM99} (con relativi algoritmi di model checking), le equivalenze comportamentali (con relativi algoritmi di decidibilita') {KM99,BCIM99, IYW00} e tecniche di constraint solving {HIM00}. Un approccio interessante e legato alla caratterizzazione multi-viste della AS come in UML. Ogni vista e caratterizzata da un diagramma, cioe un grafo, e viste diverse possono essere relazionate tramite delle nozioni decidibili di consistenza (FLP99). Per quanto riguarda lanalisi qualitativa, di recente si sono consolidate metodologie di validazione di indici di qualita' di tipo quantitativo (tipicamente la performance), a partire da descrizioni di progetto di una applicazione nell'area di sistemi "stabili" (CIM00, ABI01, SG98, WS98). Viceversa, ci sono pochi risultati, spesso limitati all'analisi "ad hoc" di particolari sistemi (BP98, KJG00, PRS99, SDS99, SS97), nel campo dei sistemi distribuiti in ambienti con un alto grado di instabilita', dovuta ad esempio alla presenza di mobilita' fisica e logica. Una ultima linea di ricerca rilevante nel contesto del progetto SAHARA e relativa alle tecniche di raffinamento. Dal punto di vista architetturale ci sono stati nel passato degli approcci dichiarativi al raffinamento di architetture software (MQR95), piu recentemente e stato proposto un approccio basato su una logica temporale per sistemi distribuiti con mobilita e su metodi formali di raffinamento (FMSS00). Una altra promettente tipologia di raffinamento e quella definita a partire da descrizioni architetturali basate su Abstract State Machines (ASM) (CSL00). Testo inglese THEME1. Definition of rigorous notations and techniques for HASA. The role of SA in the development of large complex systems is widely recognized both in academia and industries. In the last years many languages to describe SA have been proposed. These range from architectural languages, the so called Architecture Description Languages (ADL) {MT00,BHH99} specifically designed to describe SA, to design notations like UML (JBR99,GAK00,HNS00,etc.). Although no general consensus emerged on the SA notational side , we are facing a general tendency at integrating architectural concepts and notions in standard design notations, notably UML. This seems to be a natural evolution due to the growing interest in using and applying architectural concepts in the scope of real large scale industrial projects. The emergence of UML, a unifying and very successful notation, might offer a straightforward solution to the SA notational and conceptual framework problem. Despite the flourishing of attempts, dating back since the early UML age, many of the concepts emerged in the field of software architectures do not find an immediate and/or agreed upon correspondence in the UML notation. Witness the panel devoted to this subject within the <> 2000 conference. The solutions proposed for these notational problems are typical of UML, namely the definition of profiles and the "metamodelling". A profile provides mechanisms for specializing its reference metamodel in specific domains, for example to model real-time systems or business objects [OMG99]; or even software architectures [MKS00]. Metamodelling refers to visual and OO techniques proposed for conveniently and rigorously defining profiles and the notion of profile itself, in order to provide a precise standard. Recently the schema of a metamodelling approach has been submitted to the OMG (Object Management Group), based on ML (a minimal kernel of UML), aiming to cover the complete definition of UML, syntax, semantics and extensions (COO00). A difficult part to model are the dynamic aspects of UML, for these techniques based on labelled transition systems can be used leading to the discovery of many problematic points (RAC00). The same techniques play a fundamental role in the definition of the UML systems, which are the elementary bricks within a multiview approach to the semantics of UML [RCA01]. It remains problematic to describe the process behaviors; the current metamodelling techniques are indeed unsatisfactory in that respect. Currently these are limited to a narrative in natural language or to the use of OCL (Object Constraint Language), the formal notation adopted as a quasi-standard with UML for expressing properties about objects, but restricted to pre/post-conditions as far as behaviours are concerned. As far as ADL are concerned, there exist proposals of design paradigms for software architectures that explicitly consider the concepts of components location and mobility to new locations, like the code on demand (COD), remote evaluation (REV) and mobile agents (MA) paradigms (FPV98). This research line also affects the language level, with proposals for languages and formalisms where location and mobility are considered "first class" concepts (CG98, RM98, TSE98). Another open research area concerns the ability to embody quantitative information in the architectural descriptions. In this field the approaches range from integrated formalisms for behavioural and quantitative descriptions, like stochastic process algebras {eg. BCD00} to annotation techniques of the design artefacts all along the development process, notably as devised in a UML like development process {CM00,P00}. How to express quantitative indices concerning mobility issues has only recently been addressed (GC00). THEME2. Characterization of SA for classes of HASA. The study of SA for HASA applications is largely immature due to the HANI innovative nature and its lack of availability. Nevertheless there exist classes of actual applications whose architectural features can constitute a good starting point for the study of SA for HASA. Focussing on new software infrastructures for Internet or even Web applications, there is an increasing emphasis on the idea of "software as a service". A recent example is Microsoft1s .NET initiative, which partially originates from RPC and DCOM/CORBA. .NET is a software infrastructure offering uniform mechanisms to access remote services. It consists of a number of protocols for components, like SOAP, which is based on HTTP and XML. The protocols are intended to develop new network services enabling more complex coordination and cooperation services. .NET is also relevant because it puts forward markup languages as a powerful tool to express complex relationships among data and documents. Markup languages allow to organize data with a declarative approach, and can be applied to a variety of problems in software engineering. The XML-based technologies called XSLT, Xlink and Xpointer can be used to develop document management systems integrated with an advanced hypertext-based interface in order to support special notations, like UML, or sophisticated user interfaces, like those which support hand-held computers, etc. Of interest are also the experiences developed in designing WAP-based applications, where devices limitations and the inherently unreliable, unstable and unpredictable conditions of the wireless networks must be taken into account. At the same time these applications can be very demanding in terms of QoS, like for m-commerce where transactions and security must be provided. In these situations the traditional client-server paradigm, largely used in e-commerce applications does not work and new architectural models must be proposed to exploit at best the features that the underlying infrastructure can offer {VV00,ON01}. Another architectural paradigm is suggested by the popular Internet systems like Napster (http://www.napster.com), Gnutella (http://www.gnutella.org) and Freenet (http://freenet.sourceforge.net). In these systems the traditional client-server architecture shifted to a peer-to-peer one, where users directly host the resources they want to share globally without any need for publishing them on a server. In a mobile scenario, especially in ad hoc networks, the interaction pattern suggested by this architecture seem to be the most natural. Software architectures to support the migration of legacy systems can be another source of inspiration. In the past years: each relevant technology or methodology innovation forced organisations to adapt, port, reengineer existing software systems to save not only investments but also knowledge, business rules and engineering solutions. Examples are the migration from batch to interactive systems, from monolithic to client-server architectures, the paradigm shift from procedural to object oriented systems and so on. The migration towards HANI can rely on a this solid background. Here one challenging factor is the definition of a suitable architectural reference model to support the definition of methods and techniques to single out architectural concepts in the original legacy code. In the context of re-engineering procedural code to object-oriented architectures, there have been several approaches that differ for the granularity of the recovered objects, their persistency, the typology of considered programming language and the level of required human intervention (CCM96,L97,GK00). Relevant results were also achieved in the migration of monolithic architectures towards client-server solutions. In this area, results are available to plan, organize and control the migration process (BS95,B96,S99). Results are also available to tackle technical issues such as identifying the client(s) and server(s) components (SN94, CCD00) and reengineering them (ACC01). Of interest are also reverse engineering methods and tools aimed at recovering architectural views from existing systems (FAT99,HRY95,YHC97). THEME3. Middleware for HASA. Recently the middleware became a technological component of growing interest. Citing from the OM 2001 workshop (http://www.cs.wics.edu/~bodik/om2001/cfp.html): Middleware software is an intelligent plumbing that connects the client side of a distributed application with a database or a web server. The term middleware is intended to extend far beyond the current industrial technologies for e-commerce applications. Roughly, it is meant to include all systems software that provides enabling services needed by a distributed application, for example: connectivity software that allows multiple processes interact across a network, Java virtual machines that execute the communicating software components, and operating systems and run-time libraries that schedule parallel execution threads. Middleware therefore is an application programming interface supporting abstractions that simplify the chore of developing applications in a specific domain. Examples are the architectures and platforms for component programming like RM-ODP, CORBA, RMI and DCOM. Critical relevance has the middleware for heterogeneous networks: The focus of Middleware 2001 is on the design, implementation, deployment and evaluation of distributed systems platforms and architectures for future networked environments. Of particular interest is the experience in environments which may include public, private and mobile networks, overlaid wired and wireless technologies, IPv6 and IP multicast, multimedia and real-time information and an increasing volume of WWW and Java traffic. Equal concern there exists for the Middleware for Mobile Computing The software infrastructure to support mobile applications is becoming critically important to the next horizon in computing. This one-day workshop this emerging area of middleware for mobile computing.(http://www.labs.agilent.com/middleware2001/). Several technologies can be considered in the HANI perspective. In HANIs the assumption, classical in the distributed system domain, that network topology is statically determined does not hold. In the programming languages domain Java enables the design of software systems based on the mobile code paradigm. By exploiting mobile code, distributed applications can dynamically relocate some components over the network. Therefore, parts of the application can be moved close to the distributed resources they access. This increases flexibility in resource usage, limits the usage of communication channels, and supports disconnected computational modes, where a node of the system moves "mobile agents" able to autonomously execute some task close to the interesting resources and then temporary disconnects itself from the system. These aspects are particularly relevant in the HANI context where wireless communication channel are typically noisy and provide low bandwidth, and the probability that a disconnection occurs is so high to be a characteristic of this application domain. Other crucial aspects in the HANI context are architectural paradigms and middleware that support communication between mobile components. T-Space {LMW99}, JavaSpace {SUN99}, and LIME {MPR99} are middleware where communication between components is mediated by a virtual common workspace. Components access this workspace both to read and to write data (tuple). The underlying model, Linda {CG89}, has been applied in the parallel computation domain and it has been extended to support coordination between components. Linda enables decoupling between parts involved in a communication. This is an important property in the HANI context where the probability that parts of the network are disconnected is high. According to the event-based paradigm and the corresponding middleware {CNF01}, components of a software system interact by generating and receiving events. The event is sent to a channel or dispatcher that forwards it to all components interested in receiving it. The channel acts as an intermediary between the source and the destination, thus decoupling them. It is then possible to support communication between parties that can be temporary disconnected from the network at different time instants. Some proposals combine Linda and the event-based paradigms with more traditional object-oriented approaches. This is the case of CORBA {OMG98} and Jini {E00}. Techniques supporting legacy systems integration, like wrapping, have been winning features for middleware like CORBA. Wrapping technology (AC96, M94, S96, S00) plaied a key role in the migration of legacy systems towards network infrastructures. A wrapper is a software layer that encapsulates a legacy component, or an entire application. The wrapper interface allows for message passing among new and legacy components, and thus for integration. Legacy systems can be wrapped at different levels of granularity, including function/transaction encapsulation, data encapsulation, and user interface encapsulation (CCD99, ACC01). THEME4. Analysis and Validation of SA for HASA. The description of SAs is traditionally based on graphical formalisms that cater with the static facets (notably UML) and on various other formalisms to cope with the dynamic facets: most are operational in nature, like the Chemical Abstract Machine {IW95} and process algebras {AG97,GMC99}, and a few are more declarative, typically temporal logics {WF98}. With respect to the kind of analysis that can be performed on the descriptions in these notations, we find that only functional aspects are considered in most cases. Only recently there have been attempts to take into consideration the problems related to mobility, either physical or logical {CFM00,PMR01}, and to quality issues, albeit limited to performance analysis {WS98,ABI01}. From the functional side well known techniques in the field of the analysis, verification and validation have been used. Most used in the SA setting are graph/term rewriting and constraints solving techniques {HIM00}, temporal, modal logic, corresponding theorem proving or model checking techniques and behavioural equivalences {KM99,SM99}, etc. An interesting approach concerns the description of a SA as a set of views as for example in the UML process. Each view is a diagram, i.e. a graph, and different views can be formally mapped through decidable notions of consistency and semantic coherence {FLP99}. As far as quantitative analysis is concerned while validation methodologies for quantitative quality indexes (like performance), starting from design artifacts are relatively addressed for stable systems (SG98,CIM00, P00), few results exist for "unstable" distributed systems where the instability is mainly due to the presence of physical or logical mobility, often limited to "ad hoc" analysis of particular systems (KJG00, SMA99, SS97). A further research topic of relevant interest in the context of the SAHARA project deals with refinement techniques. For SA there has been in the past declarative approaches to deal with correctness preserving refinements of Sas {MQR95}. More recently an approach to refinement based on a temporal logic for distributed systems with mobility has been proposed {FMSS00}. Another interesting research area starts from SA descriptions based on Abstract State Machines (ASM) which are equipped with a rigorous refinement method {CSL00}. ------------------------------------------------------------------------ 2.2.a Riferimenti bibliografici {ABI01} F. Aquilani, S. Balsamo, P. Inverardi Performance Analysis at the software architecture design level, to appear in Performance Evaluation. {ACC01} L. Aversano, G. Canfora, A. Cimitile and A. De Lucia Migrating Legacy Systems to the Web: An Experience Report, in IEEE 5th Conf. on Soft. Maint. and Reeng., 2001. {AG97} R. Allen, D. Garlan A Formal Basis for Architectural Connection, ACM TOSEM, July 1997. {BS95} M. L. Brodie and M. Stonebraker (1995) Migrating Legacy Systems Morgan Kauf.. {BCD00} M. Bernardo, P. Ciancarini and L. Donatiello, "AEMPA: A Process Algebraic Description Language for the Performance Analysis of Software Architectures", in 2nd ACM Wosp, 2000. {BHH99} Leonor Barroca, Jon Hall, and Patrick Hall, editors. Software Architectures -- Advances and Applications. Springer, 1999. {BIM01}A. BERTOLINO, INVERARDI P., H. MUCCINI. An Explorative Journey from Architectural Tests Definition downto Code Tests Execution. ACM ICSE 2001. {CCD99} G. Canfora, A. Cimitile, A. De Lucia, G.A. Di Lucca Devising Coexistence Strategies for Objects with Legacy Systems, in Object-Oriented Tech. and Computing Systems Re-Eng., H. Zedan and A. Cau ed., Horwood Publishing Limited, UK, 1999. {CCD00} G. Canfora, A. Cimitile, A. De Lucia and G. A. Di Lucca Decomposing Legacy Programs: A First Step Towards Migrating to Client-Server Platforms, The Jou. of Systems and Soft., vol. 54, 2000. {CDF99} A. Cimitile, A. De Lucia, G. A. Di Lucca and A. R. Fasolino Identifying Objects in Legacy Systems Using Design Metrics, The Jou. of Systems and Soft., vol. 44, 1999. {CFM00} P. Ciancarini, F. Franze`, and C. Mascolo. Using a Coordination Language to Specify and Analyze Systems containing Mobile Components. ACM TOSEM, 9(2). April 2000. {CG89} N. Carriero and D. Gelernter, Linda in Context, in Comm. of ACM, 32, 4, 1989. {CG98} L. Cardelli, A.D. Gordon Mobile ambients, in FSSCS, LNCS-1378, 1998. {CIM01} C. Colafigli, P. Inverardi, R. Matricciani, InfoParco : an experience in designing an information system accessible through WEB and WAP interfaces, HICSS 34, 2001. {CIM00} Cortellessa V., Iazeolla G., Mirandola R., Early Generation of Performance Models for Object Oriented Systems, IEE Software, Vol. 147, No. 3, 2000. {CM00} Cortellessa V., Mirandola R., Deriving a Queueing Network Based Performance Model from UML Diagrams. 2nd ACM WOSP, 2000. {CNF01} G. Cugola, E. Di Nitto, A. Fuggetta The JEDI Event-Based Infrastructure and its Application to the Development of the OPSS WFMS, to appear in TSE. {COO00}S. Cook. The UML Family: Profiles, Prefaces and Packages. In UML 2000, LNCS 1939, 2000. {CSL00} E. Boerger, J.Schmid. Composition and Submachine Concepts for Sequential ASMs. 14th CSL LNCS 1862, 2000. {TSE98} Special issue on Mobility and Network Aware Computing. IEEE TSE, vol. 24, no. 5, 1998. {E00} W. Keith Edwards, Core Jini[tm], Prentice-Hall (2nd Edition, 2000). {FAT99}R. Fiutem, G. Antoniol, P. Tonella and E. Merlo ART: An Architectural Reverse Engineering Environment, Jou. of Software Maint. Research and Practice, vol. 11, 1999. {FMSS00} Ferrari, G., Montangero, C., Semini, L. and Semprini, S. Mobile Agents Coordination in Mob_adtl. COORDINATION 2000. LNCS 1906, Springer. {FPV98} A. Fuggetta, G.P. Picco, G. Vigna Understanding code mobility, IEEE TSE, vol. 24, no. 5, 1998. {FLP99} P. Fradet, D. Le Metayer, M. Perin Consistency Checking for Multiple View Software Architectures, ESEC/FSE 99, Soft. Eng. Notes, Vol.24, Num.6, 1999. {GAK00} David Garlan and Andrew J. Kompanek. Reconciling the needs of architectural description with object-modeling notations. UML 2000, LNCS 1939, 2000. {GMC99} D. Giannakopoulou, J. Kramer, and S.C. Cheung. Analysing the Behaviour of Distributed Systems using Tracta. Journal of Aut. Software Eng., Vol. 6, Issue 1, 1999. {GC00}Grassi V., Cortellessa V., Performance Evaluation of Mobility-based Software Architectures, 2nd WOSP, 2000. {GK00}J. F. Girard and R. Koschke A Comparison of Abstract Data Types and Object Recovery Techniques, SCP, vol. 36, no. 2-3, 2000. {Har00} M.J. Harrold. Testing: A Roadmap, The future of software engineering, ACM Press, 2000. {HNS00} C. Hofmeister, R. L. Nord, D. Soni Applied Software Architectures, Addison Wesley, 2000. {HIM00} D. Hirsch, P. Inverardi, U. Montanari. Reconfiguration of Software Architectures Styles with Name Mobility, COORDINATION2000, LNCS 1906. {IW95} P. Inverardi, A.L. Wolf. Formal Specifications and Analysis of Software Architectures Using the Chemical Abstract Machine Model. IEEE TSE, 21(4), 1995. {JBR99} I. Jacobson, G. Booch, and J. Rumbaugh. The Unified Software Development Process. Addison Wesley, 1999. {KM99} J. Kramer, J. Magee. Concurrency: State Models and Java Programs. Wiley Publisher, 1999. {KJG00} D. Kotz, G. Jiang, R. Gray, G. Cybenko, R.A. Peterson Performance analysis of mobile agents for filtering data streams on wireless networks, MSWiM 2000. {L97} A. Lakothia A Unified Framework for Expressing Software Subsystems Classification Techniques, The Jou. of Systems and Soft., vol. 36, 1997. {LMW99} T.J. Lehman, S.W. McLaughry, P. Wyckoff. TSpaces: The Next Wave, in HICSS-32, January 99. {Man00} S. Mann Programming Applications with the Wireless Application Protocol; Wiley 2000 {MKS00} M. Mancona Kande' and A. Strohmeier. Towards a UML profile for software architecture. In UML 2000, LNCS 1939, 2000. {MPR99} Amy L. Murphy, Gian Pietro Picco, and Gruia-Catalin Roman. Lime: Linda Meets Mobility, ICSE'99, May 1999. {MQR95} M. Moriconi, X. Qian, R. A. Riemenschneider Correct Architecture refinement, IEEE TSE, 21 (4), 1995. {MT00} N. Medvidovic and R. Taylor. A Classification and Comparison Framework for Software Architecture Description Languages. IEEE TSE 26(1), 2000. {ON01} D. Olsson, A. Nilsson MEP A Media Event Platform, HICSS 34, 2001. {OMG98} Object Management Group, CORBA/IIOP 2.2 Specification, February 1998, ftp://ftp.omg.org/pub/docs/formal/98-07-01.pdf {OMG99} OMG. OMG white paper on the profile mechanism (1.0). Tech. Rep. ad/99-04-07, 1999. {P00} D. Petriu Deriving Performance Models from UML Model by Graph Transformation , 2nd WOSP, 2000. {PMR01} G.P. Picco, G.-C. Roman, P.J. McCann Reasoning about code mobility with Mobile UNITY, To appear in ACM TOSEM {RAC00} G. Reggio, E. Astesiano, C. Choppy, and H. Hussmann. Analysing UML Active Classes and Associated State Machines -- A Lightweight Formal Approach. FASE 2000 LNCS 1783, 2000. {RCA01} G. Reggio, M. Cerioli, and E. Astesiano. Towards a Rigorous Semantics of UML Supporting its Multiview Approach. FASE 2001 LNCS 2029, 2001. {RM98} G.-C. Roman, P.J. McCann An introduction to Mobile UNITY in Parallel and Distributed Processing, LNCS 1388, 1998. {RPM00} G.-C. Roman, G.P. Picco, A.L. Murphy Software engineering for mobility: a roadmap, The future of software engineering, ACM Press, 2000. {SM99} Semini L., Montangero C. A Refinement Calculus for Tuple Spaces. SCP vol. 34:2, 1999. {S96}H. M. Sneed Encapsulating Legacy Software for Use in Client/Server Systems, in IEEE Work. Conf. on Reverse Eng., 1996. {S00}H. M. Sneed Accessing Legacy Mainframe Applications via the Internet, IEEE 2nd Int. Work. on Web Site Evolution, 2000. {SMA99} Proc. 1st Int. Symp. on Agent Systems and App. and 3rd Int. Symp. on Mobile Agents , 1999. {SG98} B. Spitznagel, D. Garlan Architecture-based performance analysis, 1998 Conf.on Soft. Eng. and Know. Eng. {SS97} M. Strasser, M. Schwehm A performance model for mobile agent system, in PDPTA 97, vol. II. {SUN99} Sun Microsystems, The JavaSpaces Specification, 1999, http://www.sun.com/jini/specs/js101.html. {VV00} Upkar Varshney, Ron Vetter Emerging mobile and wireless networks, Comm. of the ACM, JUNE 2000, vol.43, no. 6. {WS98} L.G. Williams, C.U. Smith Performance evaluation of software architectures, ACM WOSP '98, 1998. {YHC97} S. Yeh, D. R. Harris and M. P. Chase Manipulating Recovered Software Architecture Views, ICSE97, 1997. ------------------------------------------------------------------------ 2.3 Numero di fasi del Programma di Ricerca: 2 ------------------------------------------------------------------------ 2.4 Descrizione del Programma di Ricerca Fase 1 Durata:12 mesi Costo previsto: 400 M 206.583 Euro Descrizione: Testo italiano Introduzione al programma di Ricerca Il programma di ricerca e' strutturato in quattro temi, Definizione di notazioni e tecniche architetturali rigorose per HASA, Caratterizzazione di Architetture Software per classi di HASA, Middleware per HASA, Analisi e convalida di architetture per HASA ed e' organizzato temporalmente in due fasi. All'interno di ciascuna fase sono state individuate delle pietre miliari che rappresentano momenti di sincronizzazione e verifica delle attivita' in corso nelle varie unita'. La tabella sottostante riassume l'organizzazione temporale delle attivita' di ricerca ed i milestone nelle due fasi. Di seguito alle due fasi vengono riportate le tabelle, relative alla organizzazione di ciascuna fase. Accanto alle specifiche attivita' di ricerca organizzate sequenzialmente all'interno delle due fasi, e' stata individuata una attivita' parallela per tutta la durata del progetto relativa a: - gestione, autovalutazione e controllo del progetto; - trasferimento di informazioni e conoscenze, seminari e giornate di studio, evoluzione del sito WEB. Questa attvita' mette in evidenza la necessita' di un attivita' esplicita' di organizzazione e management del progetto e l'esistenza di momenti comuni durante tutto il progetto. L'adeguatezza delle varie proposte sara' anche valutata considerando un insieme comune di casi di studio, che saranno definiti nella prima fase del progetto. I casi di studio saranno determinati in funzione delle architetture software che verranno selezionate come rappresentative di alcune classi di applicazioni HASA. Nella fase iniziale del progetto verra' realizzato un sito WEB che collezionera' tutte le informazioni relative al progetto e che fornira', momento per momento, lo stato di avanzamento dei lavori, in termini di attivita' delle varie unita', rapporti tecnici, pubblicazioni e software prodotto. La Unita' dell'Aquila si occupera' della gestione di questo sito WEB. Tabella riassuntiva [Image] I FASE Per quanto riguarda le attivita' verticali, la prima prevede tre mesi di omogeneizzazione delle conoscenze con incontri e seminari come periodo di inizializzazione del progetto. Questo periodo e' relativamente breve poiche' la maggior parte delle unita' operative proviene da una comune esperienza progettuale su tematiche affini. I successivi sei mesi saranno dedicati a sviluppare due attivita' in parallelo: da una parte si studieranno le tipologie di applicazioni HASA che possono essere realizzate su infrastruttura HANI, da questa analisi emergeranno un insieme di architetture software di riferimento per ciascuna delle classi di HASA identificate; dall'altra verranno studiate le tipologie di infrastrutture HANI, anche attraverso l'analisi delle proposte di standardizzazione attualmente in corso per reti di terza generazione, per determinare delle caratteristiche possibili del middleware. I risultati di queste due attivita' parallele verranno discusse in un incontro finale allo scopo di determinare l'insieme di architetture software di interesse e definire le caratteristiche del middleware. Gli ultimi tre mesi della prima fase verranno dedicati a definire il mapping tra AS e middleware, in modo da offrire una base rigorosa per la successiva definizione delle proprieta' di interesse che si intende supportare sia a livello implementativo come middleware sia a livello di analisi architetturale. Questa attivita' consistera' nel verificare la possibilita' di soddisfare i requisiti di qualita' del servizio e consapevolezza del contesto espressi dalle AS selezionate da parte del middleware. Allo stesso tempo la definizione di questo mapping consentira' anche di stabilire la rispondenza delle metodologie di analisi e validazione possibili a livello architetturale in termini della validazione della implementazione (sul middleware) delle HASA. In relazione ai quattro temi introdotti, alla fine del primo anno si potra' sostanzialmente considerare concluso il Tema 2. Gli altri tre Temi, viceversa, rimarranno attivi anche nella seconda fase temporale, come emerge chiaramente dalla tabella riassuntiva. Tabella I FASE [Image] Testo inglese Introduction to the Research program The project research plan includes four themes: Definition of rigorous notations and techniques for HASA, software architectures fo HASA, middleware for HASA and analysis and validation of SA for HASA. The research plan will be developed in two phases. Each phase includes specific milestones to verify and assess the activities developed by all participating sites. The table below summarizes the temporal organization of the research plan and the milestones. Following the description of each phase a table relative to that phase only is reported. Besides the main activities, sequentially organized on a temporal scale, a parallel activity has been introduced all along the project lifetime. This activity includes monitoring, evaluating and managing the project itself as well as all the permanent activities connected with information exchanges inside the project, e.g. seminars, meetings, etc. We will select a number of common case studies in the first phase to be used to evaluate the various methods, techniques, languages and tools proposed. The case studies will be selected depending on the SA that will be single out as representative of classes of HASA. In the initial phase of the project a WEB site of the project will be realized. In this site all the information about the project will be collected. That is, sites activities, technical reports and publications, software. The site in L'Aquila will take care of the WEB site. Tables for PHASE 1 e PHASE2 [Image] PHASE I As far as the main temporal activities are concerned, the first one foresees three months of knowledge amalgamation by means of meetings and seminars as project start up. This period is relatively short since most of the groups have already worked together on close subjects. The next six months will be devoted to develop two parallel activities:on one side there will be a study on the possible application domains which characteristic of HASA. From this study a set of reference SA for classes of HSA will be single out. On the other side tehre will be a study of the various typologies of HANI networks, also by looking at the on going standardization activities in the field of the specification of a standard interface for 3G (third generation) networks. This study is finalized at better understand the characteristic that a middleware can exhibit. The results of these two parallel activities will be discussed in a final meeting in order to define the set of SA of interest and the desirable caracteristics of the middleware. The last three months will define the mapping between the set of identified SA and the middleware. The purpose of this mapping s to offer a rigorous base on which identify the set of (context-aware and QoS) properties taht we intend to support both at an implementation level, through the middleware, and at the level of SA analysis and validation. This activity aims at verifying whether the identified properties can be actually be verified and satisfied. At the same time the definition of this mapping will allow a validation of the analysis and validation techniques possible at the SA level in terms of the actual behavior of the HASA running on the supporting middleware. As far as the four Themes are concerned, at the end of the first year the activities related to Theme 2 will be essentially exhausted. The other Themes will instead remain active all along the second temporal phase, as indicated in the above Table. Table PHASE I [Image] Risultati parziali attesi: Testo italiano Nel primo anno sono previsti rapporti tecnici e pubblicazioni su ciascuno dei punti sottoelencati. Per ciascun punto si possono avere piu' rapporti che mettono in luce approcci diversi all'obiettivo. Tutti i temi e unita' operative: Organizzazione dell'incontro di verifica per la presentazione dei risultati e la revisione critica in vista del 2 anno. Le presentazioni al workshop saranno collezionate in un volume che descrive lo stato di avanzamento del progetto. TEMA 1 Analisi delle possibili strutturazioni gerarchiche per HASA e livelli sottostanti seguendo lo schema di riferimento del progetto e sviluppo di un framework concettuale e tecnico per le loro presentazioni rigorose, che permetta la definizione delle relazioni che legano le AS al middleware; Proposta di tecniche di base per la metamodellazione di aspetti dinamici e loro sperimentazione applicandole a notazioni esistenti per diversi livelli architetturali. Sviluppo sperimentale di notazioni, a partire da JTN, per presentare applicazioni HASA e la loro architettura basate sul middleware Jini; relazione con il codice. Studio di uno strumento visuale (semi-)automatico che sia di supporto al progettista di HASA, rispettando lo stile architetturale e agevoli la documentazione della applicazione stessa. Studio delle proposte piu recenti di utilizzo di UML per la specifica di architetture e pattern architetturali, con anche componenti e/o agenti mobili. studio di una appropriata notazione in cui proprieta' e requisiti QoS delle applicazioni HASA vengono espressi, da usare come punto di partenza per i successivi passi di derivazione di un modello di analisi del sistema. Questa notazione potra essere formale, ispirandosi a formalismi logico-algebrici, o semi-formale per esempio come informazioni da integrare in UML. Su questo tema collaboreranno le unita' di Venezia, Bologna, Genova, LAquila, Roma Tor Vergata TEMA II Studio dei paradigmi architetturali piu` adeguati per le reti HANI. Studio delle classi di architetture software per applicazioni ad accesso eterogeneo basate su protolli WAP e IP; Studio ed analisi di architetture reali come .NET e XEON e di architetture con agenti mobili, per la gestione di documenti attivi e sistemi di workflow. Identificazione dei pattern ricorrenti e generali all'interno di classi di applicazioni innovative e significative in contesto HANI. Studio ed analisi di architetture software che supportino la coesistenza e l'integrazione di componenti legacy e componenti di nuovo sviluppo in contesti assimilabili o trasferibili ad HANI; Su questo tema collaboreranno le unita' di Milano, Venezia, Bologna, LAquila, Sannio TEMA 3 Studio e progettazione di una infrastruttura middleware chiamata XEON, capace di integrarsi con le tecnologie .NET di Microsoft. Studio e definizione delle caratteristiche fondamentali di un middleware di supporto alle applicazioni sviluppate secondo uno o alcuni dei paradigmi architetturali per HANI, si prenderanno a riferimento le varie tipologie di HANI e le proposte di standardizzazione delle interfacce per reti 3G. Studio e definizione di metodi di reengineering e wrapping per lintegrazione di applicazioni e componenti legacy in HANI; TEMA 4 definizione delle estensioni alle notazioni e alle tecniche legate a Oikos-dtl e ASM, convalidate da versioni preliminari delle caratterizzazioni delle applicazioni e delle architetture ed individuazione dei requisiti delle estensioni degli strumenti, sia visuali che di prova semi-automatica, e il relativo progetto di massima. individuazione di metodi di reverse engineering per la ricostruzione di modelli architetturali di applicazioni legacy e la loro manipolazione/trasformazione ai fini della integrazione in HANI. Le trasformazioni dovranno, in particolare, essere in grado di mappare del viste architetturali ricostruite sugli stili architetturali definiti nel tema 1; identificazione dei modelli e metodi risolutivi pi appropriati al livello di astrazione considerato, anche sulla base del confronto fra le diverse tipologie di modelli stocastici di prestazione finora studiati e basati su diversi paradigmi. I modelli devono essere in grado di esprimere efficacemente la dinamica del sistema e il suo impatto su determinati indici di qualita'. Studio di metodologie principalmente basate sul model-checking, riscritture di grafi, equivalenze comportamentali e testing per verificare e validare attributi funzionali ed extra-funzionali delle applicazioni HANI. Definizione delle relazioni tra le AS selezionate e le caratteristiche del middleware come risultanti dai Temi 2 e 3 Tutti i temi e unita' operative: Organizzazione dell'incontro di verifica per la presentazione dei risultati e la revisione critica in vista del 2 anno. Le presentazioni al workshop saranno collezionate in un volume elettronico che descrive lo stato di avanzamento del progetto. Testo inglese As result of the first year we will deliver technical deliverables concerning the following issues: For each topic more than one deliverable can be issued. TEMA 1 Analysis of possible hierarchical structuring for HASA and underlying layers, following the reference schema of the project; development of a conceptual and technical framework for their rigorous presentation which should allow for the definition of the mapping between SA and middleware; Proposal of basic techniques for the metamodelling of dynamic aspects, with application to existing notations for the different architectual layers. Experimental development of notations, from JTN, for HASA presentations and their architectures, based on the Jini middleware; relation with Java code. Proposal for a (semi-automatic) visual tool to support the HASA SA design, forcing a chosen architectural style and helping in mantaining design documentation. Study of the most recent proposal of UML use for the description of SA and architectural patterns of HASA possibly with mobile components/agents. Study of a suitable noation for HASA properties and requirements. This notation should allow for easy derivation of analysis models. It can be either formal, i.e. algebraic-logic notations, or semi-formal, including diagrammatic and textual notations integrated in UML. The groups in Venezia, Bologna, Genova, LAquila, Roma Tor Vergata will work on this Theme. THEME II Study of architectural paradigms that are most suitable to HANI networks. Characterization of SA classes for HASA based on WAP and IP protocols; Study and analysis of real architectures like .NET and XEON and of agent-based architectures for the management of active documents and workflow; Characterization of recurrent architectural patterns in classes of HASA. Study and identification of software architectures that support the coexistence and the integration of legacy components and newly developed components in HANI-like contexts; The groups in Milano, Venezia, Bologna, LAquila, Sannio will work on this Theme. THEME 3 Study and design of an actual middleware infrastructure, XEON, able to coexist and integrate with Microsoft .Net technologies; Study and definition of the basic characteristics of a middleware infrastructure to support HASA. It will be taken into account the various HANI typologies and the 3G standardization interface proposals. Study and definition of reengineering and wrapping methods to actually integrate the legacy components into a HANI; TEMA 4 the definitions of the notational extensions to Oikos-adtl and ASM, as well as of the related techniques, their partial validation via the preliminary characterizations of some of the applications and architectures, the requirements of the tool extensions, and their preliminary design. identification of reverse engineering methods to recover architectural views of a legacy system and of transformation strategies to adapt them to HANI. In particular, the transformations will aim at mapping the recovered architectural views onto the architectural styles defined in theme 1; identification of the most appropriate performance analytical and simulation models and solution techniques for the SA level of abstraction, by comparing various types of stochastic performance models proposed in the literature and based on different paradigms. Models must be expressive in terms of the inpact the system dynamics can have on selected qualities indices;br> Study of verification methodologies based techniques as model checking, graph rewriting, behavioral equivalences and specification-based testing to verify and validate the attributes of interest in HASA; Definition of teh mapping between the selected SA and the middleware as defined from Theme 2 and 3. All themes and sites: Workshop to present and evaluate results of first year. Electronic proceedings of the intermediate project workshop. Unita' di ricerca impegnate: * Unit n 1 * Unit n 2 * Unit n 3 * Unit n 4 * Unit n 5 * Unit n 6 * Unit n 7 * Unit n 8 Fase 2 Durata:12 mesi Costo previsto: 415 M 214.330 Euro Descrizione: Testo italiano Nella seconda fase, i primi tre mesi saranno dedicati alla definizione delle proprieta' che si intende poter analizzare a livello architetturale e supportare a livello di middleware. In questa fase verranno precisamente definiti e selezionati i parametri di qualita' e consapevolezza del contesto per i quali pensiamo di offrire metodi, strumenti di analisi e validazione e supporto middleware. Questa attivita' viene costruita sui risultati della attivita' precedente nella quale viene definito il mapping tra AS e middleware e riguarda specificatamente l'aspetto descrittivo e definizionale di proprieta' che sono servite a guidare la definizione del mapping di cui sopra. I successivi sei mesi verranno dedicati alla realizzazione di metodi e strumenti per la analisi e validazione delle proprieta' a livello architetturale, per la realizzazione del middleware di supporto e per la validazione (testing e simulazione) delle HASA. Tabella II FASE [Image] Testo inglese In the second phase, the first three months will be dedicated to the definition of the properties of interest in HASA that we want to be able to analyse at the architectural level and support at the middleware level. During this activity the quality of service attribute and the context-aware parameters we want to support and control are precisely defined. This activity builds on the results of the first phase, and specifically on the mapping that will be defined between SA and middleware. The mapping in fact will be defined having already an idea of the set of attributes that can be possibly supported for verification and validation purposes. The following six months will be devoted to realization activities, including the implementation of prototypes to support some of the analysis at the architectural level. The implementation of the middleware will make validation of HASA through (architectural-) testing and simulation possible. The last three months allow for integration activities among the different prototypes. Table PHASE II [Image] Risultati parziali attesi: Testo italiano TEMA 1 Profili UML per le applicazioni HASA e loro architettura che utilizzino risultati del progetto in tema di proposta di middleware (Tema 3) e relativi aspetti metodologici. In relazione alla individuazione delle propriet significative per le applicazioni HASA, ottenute nella primi tre mesi della 2 FASE, definizione delle tecniche e notazioni per esprimerle e definizione del loro uso nel processo di sviluppo. Applicazione ai casi di studio individuati nel progetto. TEMA 3 prototipazione di strumenti di supporto ai metodi di reengineering e wrapping per lintegrazione di applicazioni e componenti legacy in HANI definiti nella prima fase; progettazione e realizzazione prototipale del middleware definito nella prima fase; applicazione ai casi di studio, incluso lo valutazione della infrastruttura reale XEON a supportare architetture software complesse, specie con agenti mobili, per la gestione di documenti attivi e sistemi di workflow. TEMA 4 Definizione delle proprieta di qualita di interesse consolidamento degli sviluppi metodologici di reverse engineering per la ricostruzione di modelli architetturali di applicazioni legaci in HANI; prototipazione degli strumenti individuati nella fase 1 e consolidati a valle della definizione delle proprieta di interesse (a tre mesi dallinizio della 2 FASE) applicazione delle tecniche e degli strumenti di analisi sia funzionali che quantitativi ai casi di studio. Tutte le unita' sperimenteranno le loro proposte sull'insieme di casi di studio comuni scelti alla fine della prima fase. Tutte le unita' parteciperanno alla fase di integrazione per validare le proposte di AS e middleware. Alla fine del progetto sara' organizzato un workshop aperto a contributi esterni per la valutazione globale dei risultati ottenuti. I risultati piu' rilevanti saranno collezionati in un volume finale sulla attivita' del progetto. Testo inglese THEME 1 UML profiles for HASA applications and their architecture, based on the results of the project. Analysis of significant properties for HASA applications; techniques and notations for their representation; their use in the software development process. Application to the project case studies; THEME 3 prototyping of supporting tools to the re-engineering methods and to the wrapping techniques for the integration of legacy components in HANI, as defined in the first phase; design and prototype of the middleware defined in the first phase; application to case studies, included the evaluation of the suitability of the XEON middleware to support complex agent-based SA to manage active documents and workflow; THEME 4 Definition of the properties of interest in HASA further development of the theoretical and methodological achievements of the first year in the reverse engineering of architectural models for legacy components in HANI; prototypes of the tools identified in the first phase and selected after the definition of the properties of interest (three months after the beginning of Phase two) application of techniques and tools for behavioral and quantitative analysis to the case studies; All sites: Analysis of their own proposals with respect to common case studies defined at the end of the first phase. All sites: Integration effort of the single methods and tools in order to validate the proposed SA and the middleware. Open workshop to present and evaluate the final results of the project. The most relevant results will be collected in a finale volume summarizing the project activity. Unita' di ricerca impegnate: * Unit n 1 * Unit n 2 * Unit n 3 * Unit n 4 * Unit n 5 * Unit n 6 * Unit n 7 * Unit n 8 ------------------------------------------------------------------------ 2.5 Criteri suggeriti per la valutazione globale e delle singole fasi Testo italiano Usuali criteri di valutazione scientifici per quanto riguarda le pubblicazioni, con particolare attenzione alla pertinenza dell'ambito nel quale queste verranno pubblicate, in termini di Journals o Conferenze rilevanti rispetto ai temi del progetto. Partecipazione ad i workshop interni al progetto, a valle di ciascuna fase, di revisori esterni che potranno redigere una valutazione della attivita' svolta, analogamente a quanto avviene per progetti europei. Disponibilita' per, e quindi esposizione alla, comunita' scientifica, degli strumenti e metodi, progettati e realizzati nel progetto. I rapporti tecnici ed il software prodotti nel progetto saranno disponibili sul sito WEB del progetto. Rilevanza scientifica della casa editrice che accetta la pubblicazione del volume finale della attivita' del progetto. Testo inglese Usual scientific criteria to evaluate the quality of pubblications, with particular attention to the relevance of the Journals and Conferences with respect to the themes of the projects. Presence of external referees to the project workshops. They could evaluate the activity analogously to what happens in EEC funded projects. Availability in the international community of methods, tools and pubblications produced in the project. This will be achieved through the WEB site of the project. Relevance of the publishing editor for the final volume collecting the results of the project. ------------------------------------------------------------------------ Parte: III 3.1 Spese delle Unita di Ricerca Voce di spesa, M Unit diMateriale Grandi Materiale di Spese per Personale Servizi Missioni PubblicazioniPartecipazione / Altro ricerca inventariabile Attrezzature consumo e calcolo ed a esterni Organizzazione Totale funzionamento elaborazione contratto convegni dati Unit n 1 10 10 30 40 90 Unit n 2 8 1 54 10 73 Unit n 3 30 6 35 2 20 2 10 105 Unit n 4 30 3 60 2 5 100 Unit n 5 35 10 35 5 30 28 143 Unit n 6 15 5 15 45 3 10 5 98 Unit n 7 35 13 30 7 35 30 150 Unit n 8 8 3 43 2 56 TOTALE 171 51 145 14 327 7 93 7 815 Voce di spesa, Euro Unit diMateriale Grandi Materiale di Spese per Personale Servizi Missioni PubblicazioniPartecipazione / Altro ricerca inventariabile Attrezzature consumo e calcolo ed a esterni Organizzazione Totale funzionamento elaborazione contratto convegni dati Unit n 1 5.165 5.165 15.494 20.658 46.481 Unit n 2 4.132 516 27.889 5.165 37.701 Unit n 3 15.494 3.099 18.076 1.033 10.329 1.033 5.165 54.228 Unit n 4 15.494 1.549 30.987 1.033 2.582 51.646 Unit n 5 18.076 5.165 18.076 2.582 15.494 14.461 73.853 Unit n 6 7.747 2.582 7.747 23.241 1.549 5.165 2.582 50.613 Unit n 7 18.076 6.714 15.494 3.615 18.076 15.494 77.469 Unit n 8 4.132 1.549 22.208 1.033 28.922 TOTALE 88.314 26.339 74.886 7.230 168.881 3.615 48.030 3.615 420.912 ------------------------------------------------------------------------ 3.2 Costo complessivo del Programma di Ricerca e risorse disponibili Voce di spesa Unit diRD RA RD+RA Cofinanziamento Costo Costo ricerca richiesto al totale del minimo MURST programma M Euro M Euro M Euro M Euro M Euro M Euro Unit n 27 13.944 27 13.944 63 32.537 90 46.481 90 46.481 1 Unit n 8 4.132 14 7.230 22 11.362 51 26.339 73 37.701 73 37.701 2 Unit n35 18.076 35 18.076 70 36.152 105 54.228 105 54.228 3 Unit n30 15.494 30 15.494 70 36.152 100 51.646 70 36.152 4 Unit n43 22.208 43 22.208 100 51.646 143 73.853 143 73.853 5 Unit n10 5.165 22 11.362 32 16.527 66 34.086 98 50.613 85 43.899 6 Unit n21 10.846 24 12.395 45 23.241 105 54.228 150 77.469 150 77.469 7 Unit n17 8.780 17 8.780 39 20.142 56 28.922 56 28.922 8 TOTALE 164 84.699 87 44.932251 129.631 564 291.282 815420.912 772 398.705 M Euro Costo complessivo del Programma 815 420.912 dell'Unit di Ricerca Fondi disponibili (RD) 164 84.699 Fondi acquisibili (RA) 87 44.932 Cofinanziamento richiesto al MURST 564 291.282 ------------------------------------------------------------------------ 3.3 Costo minimo per garantire la possibilit di verifica dei risultati 772 M 398.705 Euro (dal sistema, quale somma delle indicazioni dei Modelli B) 772 M 398.705 Euro (dal Coordinatore del Programma) (per la copia da depositare presso l'Ateneo e per l'assenso alla diffusione via Internet delle informazioni riguardanti i programmi finanziati; legge del 31.12.96 n 675 sulla "Tutela dei dati personali")