Generazione Automatica di Asserzioni da Modelli di Specifica

Transcript

1 UNIVERSITÀ DEGLI STUDI DI MILANO BICOCCA FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI Corso di Laurea Magistrale in Informatica Generazione Automatica di Asserzioni da Modelli di Specifica Relatore: Mauro Pezzè Correlatore: Jochen Wuttke Tesi di Laurea di: Mauro Baluda Matr Anno Accademico 2008/2009

2 ai miei genitori

3 i Sommario L individuazione di nuove tecniche per la rilevazione automatica di malfunzionamenti è importante per la verifica a run time di software complessi, è in particolare un tassello indispensabile per la realizzazione di sistemi self-healing. L analisi di malfunzionamenti in software di largo utilizzo ha permesso di riconoscere in molti di essi violazioni di proprietà strutturali ricorrenti definibili a livello di modelli di specifica. La tesi descrive una metodologia che consente di generare automaticamente il codice eseguibile per la verifica di tali proprietà, un prototipo della sua implementazione utilizzabile all intero di sistemi di sviluppo esistenti, una valutazione di tale prototipo che ne conferma l applicabilità in situazioni reali di sviluppo. Abstract The availability of automatic failure detection techniques plays an important role also in the context of self-healing systems. Analysis of failures in popular software products allowed us to identify many of them as violations of structural properties that could be defined in design specification models. In this thesis, I describe a methodology that permits to automatically generate codelevel assertions to check those properties at runtime. To evaluate the methodology I designed and implemented a prototype and I experimented the approach on several case studies.

4 Indice Introduzione 1 1 Tecniche per rilevare malfunzionamenti Testing classico Asserzioni Design By Contract Model-based testing Self-healing Rilevare difetti automaticamente Un approccio basato su Modelli Caso d uso Progettazione dei Rilevatori Identificare le proprieta di interesse Proprietà Initialized Proprietà Immutable Proprietà NotNull Proprietà Language Proprietà Comparable Proprietà Explicit Realization Sviluppo dei rilevatori ii

5 INDICE iii 4 Prototipo Tecnologie utilizzate UML JET AspectJ Eclipse Plug-in Development L Implementazione Linguaggio di specifica La trasformazione del modello Rilevatore per Initialized Rilevatore per Immutable Rilevatore per NotNull Rilevatore per Language Rilevatore per Comparable Rilevatore per Explicit Realization Utilizzare trasformazioni in Eclipse Difficoltà incontrate Risultati sperimentali Test Risultati sperimentali con Tomcat Initialized NotNull Language Analisi Conclusioni 69 A Il generatore di rilevatori 71 B I test 90

6 Elenco delle figure 1.1 Diffusione di UML Modello di HttpServletResponse Proprietà Initialized: Specifica Proprietà Initialized: Utilizzo Proprietà Immutable: Specifica Proprietà NotNull: Specifica Proprietà Language: Specifica Proprietà Comparable: Specifica Proprietà Explicit: Specifica Proprietà Explicit: Utilizo Applicazione NotNull Configurazione della trasformazione in Eclipse Modello UML per il testing Modello di JspFactory iv

7 Acronimi AOP Aspect Oriented Programming API Application Programming Interface DSL Domain Specific Language EMF Eclipse Modeling Framework LTW Load Time Weaving MDA Model Driven Architecture MDT Model Development Tools OMG Object Management Group PDE Plug-in Development Environment SDK Standard Development Toolkit SOA Service Oriented Architecture UML Unified Modeling Language XML Extensible Markup Language XMI XML Metadata Interchange XSS Cross Site Scripting v

8 Introduzione L industria del software si trova nella difficile situazione di dover armonizzare esigenze contrastanti del mercato quali la crescente complessità e criticità dei prodotti richiesti e la riduzione dei costi di produzione. La società moderna delega compiti sempre più delicati alle macchine in settori chiave come la sicurezza o la finanza anche in situazioni che potrebbero mettere a rischio la vita umana come l automatizzazione dei trasporti o provocare dissesti finanziari, si pensi alla gestione elettronica del commercio di beni e titoli finanziari. Risulta evidente in questo contesto come la necessità di garantire un elevato grado di qualità nei sistemi software cresca parallelamente alla loro criticità. Alcuni studi hanno analizzato i costi sociali ed economici derivanti da difetti di sistemi informatici dipingendo un quadro preoccupante della situazione ma evidenziando al contempo i possibili ambiti di intervento e soprattutto mettendo in evidenza come l investimento in qualità sia economicamente redditizio [23]. Anche nel caso di sistemi meno critici infatti la qualità tecnica del software prodotto si traduce in un vantaggio competitivo per le aziende, la correzione di difetti in fase precoce di sviluppo inoltre è molto meno costosa che in fase di produzione. Nonostante non sia possibile con le tecniche attuali garantire in generale l assenza di difetti nel software, l impiego oculato delle tecniche tradizionali di testing si rivela spesso molto efficace, d altra parte il costo derivante dall utilizzo di queste tecniche cresce enormemente al crescere della complessità dei sistemi testati al punto da occupare tipicamente frazioni predominanti 1

9 ELENCO DELLE FIGURE 2 del costo totale di produzione [12]. In a typical commercial development organization, the cost of providing the assurance that the program will perform satisfactorily in terms of its functional and nonfunctional specifications within the expected deployment environments via appropriate debugging, testing, and verification activities can easily range from 50 to 75 percent of the total development cost. - Hailpern and Santhanam, 2002 Per queste ragioni risulta spesso antieconomico il collaudo esaustivo delle funzionalità di un software e spesso le tecniche più onerose vengono del tutto evitate come nel caso del test di unità che dovrebbe verificare il buon funzionamento in isolamento delle più elementari unità di codice individuabili [2]. Le tecniche tradizionali di testing inoltre non si sono rivelate sufficienti nel caso sempre più diffuso di sistemi il cui comportamento emerge dall integrazione di moduli indipendenti in esecuzione in ambienti distribuiti [18]. È ad esempio il caso di Service Oriented Architecture (SOA) i cui componenti sono accoppiati dinamicamente e per i quali non è diponibile una specifica funzionale completa. La corretta integrazione di questi sistemi può essere quindi testata soltanto a run-time con tecniche dinamiche come le asserzioni in linea che permettono la verifica di condizioni specificate localmente nel codice durante lo sviluppo [22]. Le asserzioni permettono di prolungare il testing del software anche dopo la sua messa in opera e grazie alla loro semplicità concettuale e facilità di utilizzo hanno riscosso un certo successo tra gli sviluppatori. Le asserzioni riflettono il giudizio del programmatore riguardo a quali situazioni non dovrebbero verificarsi in determinati momenti dell esecuzione del programma, possono essere molto sofisticate perchè valutano qualsiasi condizione esprimibile nel codice. Proprio per la loro località e per la loro definizione a livello di codifica però le asserzioni in linea non sono generalmente utili per la verifica di vincoli

10 ELENCO DELLE FIGURE 3 strutturali dei sistemi, vincoli che potrebbero invece essere modellati durante le fasi progettuali. Da queste premesse emerge pressante la richiesta di nuove teorie, tecniche e strumenti concreti per la misura e l incremento della qualità del software [23]. Recentemente sono state proposte alcune tecniche complementari al testing tradizionale che vengono definite di self-healing, si tratta di ottenere dai sistemi software un certo grado di autonomia che permetta loro di rilevare e correggere i propri malfunzionamenti [15]. Un sistema self-healing deve dimostrare almeno tre capacità: Rilevazione di malfunzionamenti: permette al sistema di rilevare autonomamente un malfunzionamento durante la propria esecuzione Diagnosi: permette al sistema di analizzare le informazioni raccolte nella fase precedente allo scopo di individuare la causa del difetto rilevato Correzione: rimette il sistema in grado di fornire in tutto o in parte le proprie funzionalità La tesi studia e valuta una nuova metodologia per la rilevazione di difetti funzionali adatta alla loro correzione automatica. La maggior parte delle tecniche di rilevazione proposte fino ad ora si occupano di rilevare malfunzionamenti che portano ad eccezioni nel codice, alla terminazione o al blocco del sistema e non rilevano invece difetti funzionali in cui cioè il sistema produce un output diverso da quello atteso. La tesi dimostra la possibilità di definire asserzioni a livello di modellazione strutturale del software attraverso la realizzazione e l analisi di uno strumento utile al progettista per definire vincoli funzionali e verificarne il rispetto nel prodotto finito. Nella tesi proponiamo un catalogo di proprietà sufficientemente generali da poter essere applicate a molti casi reali e per ognuna di esse forniamo un implementazione adatta ad essere utilizzata per annotare modelli Unified Modeling Language (UML). Ognuna delle proprietà

11 ELENCO DELLE FIGURE 4 così definite viene poi verificata dal sistema attraverso la generazione automatica del rilevatore adatto che si occuperà anche di raccogliere le informazioni necessarie alla eventuale successiva fase di correzione del difetto. Per alcune proprietà di alto livello particolarmente rilevanti dunque il metodo solleva lo sviluppatore dalla necessità di progettare e inserire nel codice i rilevatori richiesti alla loro verifica migliorando così la sua produttività e la qualità del software prodotto. Il codice generato automaticamente non necessita di manutenzione ed è aggiornabile ad ogni modifica del modello da cui deriva. Il metodo proposto può essere inoltre utilizzato per la definizione e la verifica di proprietà non presenti nel catalogo, questa volta richiedendo la progettazione da parte dello sviluppatore del rilevatore adatto. Struttura della tesi Primo capitolo: fornisce una panoramica delle tecniche di failure detection attualmente disponibili illustrandone la caratteristiche principali, descrive come anche nel campo del testing sia possibile utilizzare strumenti di modellazione per separare la progettazione dei test dalla loro codifica. Secondo capitolo: descrive una tecnica di rilevazione di malfunzionamenti basato sulla generazione automatica di rilevatori opportuni a partire da proprietà definite in modelli di specifica. Propone un caso d uso per renderne chiara l applicabilità in situazioni reali e la facilità di integrazione con strumenti di modellazione preesistenti e di largo utilizzo come UML. Terzo capitolo: descrive nel dettaglio un catalogo di proprietà generiche utilizzabili nella modellazione di software ad oggetti, per ognuna di esse viene fornita una specifica in termini di profilo UML e viene mostrato un esempio di utilizzo. Viene descritta la metodologia con cui le proprietà

12 ELENCO DELLE FIGURE 5 sono state identificate a partire dall analisi di malfunzionamenti noti in software di largo utilizzo. Quarto capitolo: viene descritto un prototipo funzionate che permette la verifica delle proprietà definite nel capitolo precedente, l implementazione prodotta permette di applicare il procedimento oggetto di questa tesi in modo completo, partendo dall annotazione dei modelli di specifica fino alla messa in opera dei rilevatori attraverso la definizione di opportuni template. Il prodotto ottenuto può essere integrato nell ambiente di sviluppo Eclipse. Quinto capitolo: l implementazione realizzata è stata validata sperimentalmente attraverso una batteria di test che ne sollecita le funzionalità, nel capitolo viene riportata la metodologia utilizzata. Una seconda serie di test dimostra come il metodo possa essere applicato a casi reali in maniera indipendente dal resto del processo di sviluppo rilevando alcuni difetti noti in un software di alta qualità come Tomcat. Appendice A: contiene una parte del codice che implementa il prototipo descritto nel quarto capitolo. Appendice B: contiene il codice dei test utilizzati per verificare la qualità del prototipo.

13 Capitolo 1 Tecniche per rilevare malfunzionamenti Descriviamo in questo capitolo alcune metodologie di testing che sono emerse in ambito accademico e sono state adottate con successo dall industria del software. Focalizziamo l attenzione su tre ambiti particolarmente rilevanti nel contesto di questo lavoro di tesi: automazione dei test rilevazione di malfunzionamenti modellazione di procedure di testing Una panoramica più generale sui risultati e sugli obiettivi della ricerca nel campo del testing può essere trovata in [3]. 1.1 Testing classico Il problema di verificare la correttezza del software nasce parallelamente ai primi calcolatori, il testing è l attività di eseguire un programma con lo scopo di osservarne il comportamento ed identificare eventuali difetti [19]. Con il crescere della complessità dei programmi è emersa la necessità di automatizzare il più possibile questa attività. Nel campo dello test di 6

14 CAPITOLO 1. TECNICHE PER RILEVARE MALFUNZIONAMENTI 7 unità, una fase ritenuta essenziale per garantire la qualità del software in cui i componenti più elementari individuabili vengono verificati in isolamento, è necessario lo sviluppo di una notevole quantità di codice allo scopo di simulare l ambiente in cui il componente testato si troverà ad operare e per analizzare i risultati ottenuti. Un approccio all automazione che ha riscosso particolare successo è l utilizzo framework specifici che vengono indicati complessivamente come XUnit, tra questi il più conosciuto è JUnit che facilita la scrittura e la gestione automatica di test per programmi Java [2]. Più recentemente sono state proposte metodologie di sviluppo dette agili 1 che prevedono l utilizzo contemporaneo di diverse tecniche di test quali i test funzionali utilizzati per verificare che il software faccia ciò che è previsto, i test di unità, e i test indiretti effettuati dal cliente stesso durante lo sviluppo. In questo contesto è emersa una pratica più radicale chiamata sviluppo testfirst che prevede come prima attività la scrittura di test di unità, in questa ottica la scrittura del codice ha come obiettivo il successo di uno specifico test e non deve introdurre funzionalità aggiuntive, l insieme dei test per il sistema definisce così una sorta di specifica eseguibile. Il settore in cui non sembra ancora possibile ottenere una automazione soddisfacente è quello della generazione di input per i test, la generazione di input casuali non produce da sola test sufficientemente significativi ma la sua combinazione con tecniche di analisi statica e dinamica dei programmi è al centro di un considerevole sforzo di ricerca [14]. La completa automazione è uno dei punti di forza del metodo descritto in questa tesi, il codice per la verifica delle proprietà desiderate è infatti ottenuto direttamente da modelli opportunamente annotati del sistema e senza intervento manuale. 1

15 CAPITOLO 1. TECNICHE PER RILEVARE MALFUNZIONAMENTI Asserzioni Tradizionalmente il testing è visto come un attività che deve essere portata a termine prima del rilascio del prodotto finito per convincersi che esso sia di qualità sufficiente per gli scopi dell utente finale, è stato presto capito però che l analisi del comportamento di un sistema durante il suo utilizzo dopo il rilascio può fornire informazioni utili al suo miglioramento. L analisi passiva del comportamento di un sistema è evidentemente meno potente dell approccio classico potendosi limitare soltanto alla verifica che le esecuzioni osservate rispettino specifiche proprietà espresse per mezzo di asserzioni o invarianti invece che cercare di individuare attivamente i difetti. Inoltre l attività di monitoraggio potrebbe avere ripercussioni sulle prestazione del sistema. esempio asserzioni 1 static int min ( int x, int y){ 2 int m; 3 if (x < y) m = x; 4 else m = y; 5 6 assert (x<y)? m == x: m == y; 7 return m; 8 } Il codice riportato a pagina 8 mostra un esempio di utilizzo di asserzioni. La funzione Java proposta calcola il più piccolo tra due numeri, nel codice il programmatore si assicura alla riga 6 che la funzione non termini con un risultato non previsto. I vantaggi delle asserzioni in linea sono principalmente dovuti al loro stretto legame con il codice, un programmatore può descrivere le proprie assunzioni sul comportamento del programma in forma eseguibile anzichè in commenti essendo così forzato a mantenere la documentazione coerente con il codice. Un ulteriore vantaggio è che il loro utilizzo non influenza se non in minima parte il metodo di sviluppo utilizzato ed è sostanzialmente agnostico per quanto riguarda le scelte tecnologiche del progetto [22]. D altra parte,

16 CAPITOLO 1. TECNICHE PER RILEVARE MALFUNZIONAMENTI 9 come abbiamo già rilevato precedentemente, questo stesso stretto legame con l implementazione del sistema non le rende adatte alla verifica di vincoli strutturali meglio identificabili a livelli più astratti. Il metodo descritto in questa tesi produce dei rilevatori nel codice sotto forma di asserzioni in linea ma permette la loro definizione a livello di specifica strutturale. 1.3 Design By Contract Un utilizzo particolare delle asserzioni viene fatto nei contratti, originariamente introdotti a livello di classi nel software orientato agli oggetti oggi vengono adottati anche per componenti in senso più generale [17]. Un contratto stabilisce un accordo tra due frammenti di codice che interagiscono per mezzo di tre tipi di asserzioni: precondizioni, postcondizioni ed invarianti. Le precondizioni stabiliscono proprietà che devono verificarsi prima dell esecuzione di un componente, le postcondizioni riguardano il risultato ottenuto mentre gli invarianti devono essere rispettati durante tutta l esecuzione del frammento di codice. JML è il più popolare linguaggio di specifica basato su Java e può essere usato per la specifica di contratti. JML è supportato da un numero considerevole di tools che permettono la verifica a runtime dei contratti e l analisi statica dei programmi [8]. Specifiche espresse in JML possono anche essere utilizzate per la generazione automatica di test di unità [5]. Nello stesso ambito di ricerca è stato sviluppato Spec#, un linguaggio sviluppato da Microsoft che estende il linguaggio c# con i contratti [1]. Spec# ambisce a diventare una tecnologia di livello industriale per la creazione di sistemi di alta qualità coniugando facilità di utilizzo con tecnologie sofisticate di verifica formale. esempio Spec# 1 public int []! a = new int [ 100];

17 CAPITOLO 1. TECNICHE PER RILEVARE MALFUNZIONAMENTI public int Min () 4 ensures result == min { int i in (0: a. Length ); a[i ]}; 5 { 6 int m = System. Int32. MaxValue ; 7 for ( int n = 0; n < a. Length ; n ++) 8 invariant n <= a. Length ; 9 invariant m == min { int i in (0: n); a[i ]}; 10 { 11 if(a[n] < m) m = a[n]; 12 } 13 return m; 14 } A pagina 10 è riportato il codice Spec# per la funzione che identifica l elemento minimo in un vettore, alla riga 4 è indicata la postcondizione della funzione ed alle righe 7 ed 8 l invariante per il ciclo for. Spec# verificherà a run-time la validità delle asserzioni, in questo caso è anche in grado di verificare deduttivamente la correttezza del codice rispetto alla sua specifica funzionale data dalla postcondizione. 1.4 Model-based testing Lo sviluppo Model-driven è una metodologia che pone l accento sulla creazione di modelli, o astrazioni, che siano più vicini al dominio del problema da risolvere piuttosto che a quello della soluzione algoritmica. Si propone di aumentare la produttività dello sviluppo di sistemi semplificando il loro design e favorendo la comunicazione tra le persone coinvolte nel processo. Queste metodologie di sviluppo hanno avuto una crescita importante anche grazie alla presenza dello standard UML pubblicato a metà degli anni 90 che è stato adottato massicciamente per il design visuale del software, la figura 1.1 mostra come nel 2008 più del 70% delle società di sviluppo di software dichiaravano di usare UML ed il 22% di generare del codice applicativo direttamente da tali modelli [11]. Sarebbe desiderabile sfruttare questi modelli anche per la derivazione del-

18 CAPITOLO 1. TECNICHE PER RILEVARE MALFUNZIONAMENTI11 Figura 1.1: Da uno studio condotto da Forrester Consulting e commissionato da Unisys - Campione: 132 intervistati l attività di testing. La presenza nell industria di professionalità già in grado di usare strumenti di modellazione potrebbe facilitarne l adozione anche in questo campo ma per il momento il loro impiego è minimo probabilmente per la mancanza di pratiche e strumenti standard. Con l obiettivo di permettere agli sviluppatori di riutilizzare le loro competenze per la modellazione di procedure di test, si sta ponendo molta attenzione nell integrazione delle teniche di model-based testing con gli ambienti di sviluppo ed i linguaggi esistenti. Nel caso di UML è stato standardizzato uno specifico profilo per il testing [10]. Il metodo per la rilevazione di difetti descritto in questa tesi è di tipo model-based, anche nel nostro caso è stata posta particolare attenzione affinchè la tecnica sia integrabile in ambienti di sviluppo preesistenti e linguaggi di modellazione diffusi come appunto UML con lo scopo di facilitarne l adozione nella pratica quotidiana della produzione di software.

19 CAPITOLO 1. TECNICHE PER RILEVARE MALFUNZIONAMENTI Self-healing La ricerca nel campo di sistemi self-healing si focalizza tradizionalmente su malfunzionamenti legati alla gestione delle risorse del sistem [6] come l esaurimento della memoria o alla condivisione di risorse come nel caso di sistemi concorrenti. Sono stati proposti ad esempio sistemi che evitano il verificarsi di memory leak e buffer overflow attraverso la modifica dinamica dell ambiente in cui il sistema viene eseguito o tecniche per ritardare il collasso del sistema dovuto all esaurimento della memoria attraverso la rimozione trasparente degli oggetti non più utilizzati [20]. Altre metodologie più legate ai tradizionali sistemi fault tollerant utilizzano dei riavvii programmati del sistema o di parti di esso per evitare che possa raggiungere uno stato danneggiato irreparabilmente [4]. Tecniche di questo tipo in effetti non correggono i difetti presenti nei sistemi ma impediscono piuttosto che abbiano conseguenze sulle loro funzionalità, per questo motivo possono essere utilizzate con successo senza la necessità di rilevare nel dettaglio le cause di tali difetti [7]. La tecnica presentata in questa tesi potrebbe essere utilizzata all interno di metodologie più specifiche di correzione automatica dei sistemi grazie alla sua capacità di fornire informazioni dettagliate sul tipo di malfunzionamento rilevato.

20 Capitolo 2 Rilevare difetti automaticamente L utilizzo delle tecniche più avanzate di verifica e validazione del software permette di migliore la qualità dei prodotti sviluppati ma non garantisce dalla presenza di malfunzionamenti che possono perciò manifestarsi nella fase successiva al loro rilascio. La possibilità di ottenere una rilevazione precisa di questi eventi durante l esecuzione del sistema può consentire agli utenti di evitare le condizioni che li scatenano, segnalarne la presenza agli sviluppatori o ottenere dal sistema stesso una reazione che metta in campo strategie di autocorrezione più o meno sofisticate [13]. Nel caso di malfunzionamenti di tipo funzionale, che causano cioè un output del sistema diverso da quello atteso, perchè le informazioni raccolte durante l esecuzione del software siano effettivamente utili alla loro correzione è necessario un rilevamento particolarmente raffinato e preciso che, possibilmente, segnali il problema prima che l applicazione raggiunga uno stato inconsistente. In questo capitolo descriviamo una metodologia per la generazione di rilevatori di malfunzionamenti funzionali che potrebbe essere integrata agilmente in ambienti di sviluppo preesistenti e che sembra particolarmente adatta ad 13

21 CAPITOLO 2. RILEVARE DIFETTI AUTOMATICAMENTE 14 essere utilizzata per la realizzazione di sistemi self-healing. 2.1 Un approccio basato su Modelli Per supportare gli sviluppatori nella rilevazione di malfunzionamenti nei loro sistemi software, proponiamo una metodologia che consente la definizione di un legame preciso tra proprietà di alto livello identificabili nelle specifiche del sistema e il codice eseguibile che ne verifica la validità durante l esecuzione. La tecnica permette, a partire dall annotazione di un modello anche parziale del sistema, di generare automaticamente i rilevatori adatti sotto forma di asserzioni in linea, pronti per essere messi direttamente in esecuzione [25]. Il metodo è adatto ad essere adottato nel contesto di sistemi software orientati agli oggetti e presenta caratteristiche che lo avvicinano alle metodologie definite nell ambito della Model Driven Architecture (MDA), un approccio allo sviluppo del software che affronta la descrizione di un sistema utilizzando modelli astratti per poi, attraverso un processo di raffinamento il più possibile automatizzato, arrivare alla produzione del codice che lo realizza [16]. La caratteristica principale di queste metodologie è infatti il tentativo di rendere la fase di modellazione di un sistema parte integrante della sua implementazione finale grazie all ingente impiego di tecniche di generazione automatica del codice. La tecnica che descriveremo può essere applicata a sistemi che rispettino alcuni requisiti minimi, in particolare deve essere disponibile una specifica dettagliata seppur informale del sistema (tipicamente espressa in linguaggio naturale) ed un modello anche parziale della sua architettura. Consideriamo questi prerquisiti poco limitanti e di conseguenza l applicabilità del metodo risulta particolarmente grande. Nel resto della tesi ci riferiremo a modelli di sistemi orientati agli oggetti espressi in particolare nel linguaggio UML anche se la metodologia può in principio applicarsi anche ad altri paradigmi.

22 CAPITOLO 2. RILEVARE DIFETTI AUTOMATICAMENTE 15 Descriviamo in quattro passi come sia possibile trasformare proprietà astratte, estratte dai requisiti del sistema, nel codice eseguibile che le verifica: 1. Estrazione di informazioni dalle specifiche: L estrazione di informazioni da requisiti informali è un attività che non può essere automatizzata facilmente e che prevede da parte del progettista l individuazione di proprietà inviarianti del sistema di cui si voglia ottenere il monitoraggio durante l esecuzione. La tesi propone che queste proprietà possano essere selezionate da uno specifico catalogo che ne individua di particolarmente utili e generiche ma la tecnica è in principio applicabile a qualunque condizione verificabile durante l esecuzione di un sistema. 2. Annotazione del modello strutturale: L annotazione di un modello permette di tradurre le proprietà individuate informalmente al punto precedente in un formato che possa essere manipolato automaticamente. Poichè consideriamo la tecnica utile soprattutto per la verifica di condizioni strutturali del sistema, le annotazioni saranno applicate ad elementi di un modello strutturale dello stesso. Nel resto della tesi ci riferiremo in particolare a diagrammi delle classi espressi nel linguaggio UML ed ai loro elementi: classificatori, attributi, operazioni e ralazioni. 3. Definizione del legame tra proprietà e codice sorgente: In questa fase viene resa esplicita la semantica della proprietà che si vuole monitorare. Si definisce nel dettaglio ed in maniera dipendente dalla piattaforma su cui si vuole operare, come le informazioni disponibili nel modello possano essere utilizzate per la creazione di un rilevatore di malfunzionamenti specifico. Sarà necessario indicare quali modifiche al codice sorgente da monitorare debbano essere introdotte attraverso la realizzazione di rilevatori generici (template) istanziabili con i dati estratti dal modello.

23 CAPITOLO 2. RILEVARE DIFETTI AUTOMATICAMENTE 16 Nel caso di proprietà di utilità generale i template prodotti saranno riutilizzabili e possibilmente forniti da terze parti non richiedendo quindi l intervento del progettista nella loro definizione. 4. Generazione del codice: Una volta determinato quali invarianti debbano essere monitorati e come ciò possa essere fatto non resta che produrre il codice eseguibile che realizza i rilevatori attraverso la combinazione del modello annotato con il template adatto. Anche questa operazione sarà dipendente dalle tecnologie utilizzate nel sistema e di facile automazione nel caso di proprietà riutilizzabili. Per quanto riguarda le proprietà più generali come quelle analizzate nel capitolo successivo questi template potranno essere forniti da librerie riutilizzabili, in casi più specifici potranno essere creati template specifici. 2.2 Caso d uso Per chiarire come la tecnica descritta finora possa essere applicata a casi reali di design di sistemi ad oggetti mostriamo un esempio di utilizzo che descrive in particolare quali siano le operazioni richieste al progettista. Risulterà evidente come, nel caso di verifica di proprietà scelte da un catalogo preesistente, la procedura dimostri un elevato grado di automatizzazione riducendosi a due attività: analisi delle specifiche: il progettista dovrà riconoscere all interno delle specifiche del sistema in fase di sviluppo l applicabilità delle proprietà documentate nel catalogo che ha a disposizione. annotazione del modello: al modello del sistema (tipicamente UML) dovranno essere aggiunte le informazioni richieste dalla specifica proprietà impiegata, questa fase di annotazione permette di istanziare il template corrispondente con le informazioni necessarie ad ottenere un rilevatore

24 CAPITOLO 2. RILEVARE DIFETTI AUTOMATICAMENTE 17 di malfunzionamenti specifico per il sistema sviluppato. Supponendo di utilizzare una proprietà definita in una libreria, i dettagli su come debba essere annotato il modello saranno definiti nella documentazione fornita assieme alla stessa. Considereremo il caso di applicazioni web e di un tipico difetto di programmazione che può provocare importanti problemi di sicurezza: la mancata validazione da parte dell applicazione dell input fornito dall utente, situazione che può portare alla compromissione dell applicazione stessa. Un caso particolare di questo scenario è chiamato Cross Site Scripting (XSS) in cui la visualizzazione su di un browser internet dell input di un utente senza un opportuna verifica permette l esecuzione di codice malevolo. Ci rifacciamo ad un caso reale 1 verificatosi nel software Tomcat in cui il parametro msg del metodo senderror utilizzato per la definizione di errori personalizzati, poteva essere sfruttato per eseguire codice arbitrario nel browser dell utente di un applicazione web come dimostrato dalla seguente pagina JSP. Pagina JSP che sfrutta una vulnerabilità di Tomcat 1 contenttype =" text / html "%> 2 <% 3 // some unicode characters, that result in CRLF 4 final String CRLF ="\ u010d \ u010a "; 5 6 final String payload = CRLF + CRLF + 7 "<script type = text / javascript > 8 document. write ( Hi, there! ) 9 </ script > 10 <div style = display : none >"; 11 final String message =" Authorization required " 12 + payload ; 13 response. senderror (403, message ); 14 %> L autore della pagina JSP ha inserito nel messaggio di errore personalizzato alcuni caratteri speciali (linea 4) che una volta interpretati dal browser 1

25 CAPITOLO 2. RILEVARE DIFETTI AUTOMATICAMENTE 18 causeranno l esecuzione del codice Javascript che li segue (linee 7-10). In questo caso si tratta di codice inoffensivo ma la tecnica si presta ad essere utilizzata per il furto di informazioni contenute nel browser dell utente ed in particolare di credenziali di autenticazione a sistemi bancari e simili. Questa situazione può essere evitata facilmente verificando che l input fornito dall utente, autore della pagina web, rispetti un formato prestabilito, ad esempio che sia riconosciuto da un espressione regolare specifica. Possiamo allora immaginare una proprietà chiamata Language applicabile ai parametri di una funzione e che permetta di generare un rilevatore che verifichi i parametri di ogni chiamata di quella funzione rispetto ad una qualche espressione regolare. La proprietà è evidentemente di utilità generale e non dovrà quindi essere definita dal progettista del sistema ma possiamo immaginare che sia disponibile in un catalogo fornito da terze parti come quello presentato nel capitolo 3. Mostriamo di seguito come la procedura descritta in precedenza possa essere applicata a questo caso specifico: analisi delle specifiche: Come detto precedentemente, in software di questo tipo ci si aspetta che tutto l input dell utente sia verificato, nel nostro caso specifico questo significa che il parametro msg del metodo HttpServletResponse.sendError non deve contenere codice eseguibile. Dovrà quindi rispettare le seguenti regole: non deve contenere caratteri non stampabili non deve contenere caratteri non-ascii Utilizzando la sintassi Java tradurremo le regole citate nell espressione regolare [\p{print}&\p{ascii}]* La proprietà non è definita esplicitamente nelle specifiche del sistema, questo rende particolarmente evidente il fatto che la sua identificazione non possa essere automatizzata facilmente. annotazione del modello: Nel modello della classe HttpServletResponse

26 CAPITOLO 2. RILEVARE DIFETTI AUTOMATICAMENTE 19 annoteremo il parametro msg del metodo senderror con la proprietà Language, il che richiederà di specificare l espressione regolare che vogliamo sia rispettata. Figura 2.1: Modello di HttpServletResponse Package javax.servlet.jsp.http Proprietà: Language regexp=[\p{print}&&\p{ascii}]* «interface» HttpServletResponse attributes operations senderror( sc : int, «Language» msg : String ) classes Nel caso di un modello delle classi UML otterremmo il diagramma riportato nella figura 2.1 L utilizzo del modello così annotato come input del generatore di rilevatori fornito nel catalogo ipotizzato in precedenza, produrrà il codice che, verificando il valore del parametro prima del suo utilizzo, identifica ogni tentativo di manomissione del sistema. Il caso d uso presentato mette in evidenza alcuni dei vantaggi offerti dal metodo: non è richiesta la modellazione completa del sistema ma è sufficiente la presenza degli elementi necessari alla definizione delle proprietà desiderate una singola annotazione nel modello può produrre diversi rilevatori anche operanti in parti diverse del sistema, in questo caso il rilevatore analizzerà il funzionamento di tutte le applicazioni web in esecuzione all interno di Tomcat anche se sviluppate in maniera completamente separata

27 CAPITOLO 2. RILEVARE DIFETTI AUTOMATICAMENTE 20 non è richiesta la modifica di codice esistente, il rilevatore viene generato indipendentemente dal codice sotto osservazione il sistema permette l annotazione di modelli preesistenti con strumenti standard generalmente già conosciuti dai progettisti, in questo caso un generico editor per diagrammi UML Queste considerazioni evidenziano l estrema flessibilità della metodologia descritta e la sua sostanziale agnosticità rispetto alle altre scelte tecnologiche operate nello sviluppo del sistema da monitorare.

28 Capitolo 3 Progettazione dei Rilevatori Questo capitolo mostra la possibilità di applicare in modo utile la tecnica descritta nel capitolo precedente a casi reali, in particolare descriveremo come progettare rilevatori per malfunzionamenti partendo dall individuazione delle proprietà invarianti da monitorare. Come detto in precedenza, la progettazione di un rilevatore consiste nella definizione di una connessione precisa tra una proprietà di alto livello del sistema ed il codice eseguibile che la verifica, in questo capitolo considereremo alcune proprietà generali e per ognuna di esse definiremo come la sua applicazione possa essere modellata. Descriveremo infine come sia possibile sviluppare dei rilevatori che interagiscano con il codice da monitorare nel modo adeguato. 3.1 Identificare le proprieta di interesse In una prima fase il lavoro si è concentrato nello studio di malfunzionamenti noti in software di largo utilizzo e del loro possibile legame con proprietà strutturali identificabili nel sistema [26]. Nel caso di progetti di software libero 1 sono spesso disponibili su internet banche dati aperte al pubblico contenenti segnalazioni di malfunzionamenti

29 CAPITOLO 3. PROGETTAZIONE DEI RILEVATORI 22 e le loro eventuali soluzioni, altro fattore importante è la disponibilità per alcuni di essi di specifiche ben documentate che possano essere messe in relazione con i difetti [21]. Un progetto che si è rivelato particolarmente adatto alla nostra analisi è stato Tomcat 2, un software libero molto popolare che implementa le specifiche Java Servlet e Java Server Pages per le quali è disponibile una documentazione molto dettagliata. Tra gli altri software analizzati citiamo Cocoon 3 e Lucene 4. Dall analisi di decine di segnalazioni per difetti di Tomcat è stato possibile riconoscere in molti di essi il mancato rispetto di alcune proprietà ricorrenti. Tabella 3.1: Classificazione di difetti in Tomcat: Proprietà Classi coinvolte Difetti Initialized javax.servlet.filter javax.servlet.jsp.jspfactory javax.servlet.servlet javax.el.elresolver Immutable javax.servlet.jsp.pagecontext javax.el.expression NotNull javax.el.compositeelresolver Language servlet.http.httpservletresponse servlet.jsp.pagecontext Comparable javax.el.expression La tabella 3.1 mostra in sintesi le proprietà individuate indicando a quali

30 CAPITOLO 3. PROGETTAZIONE DEI RILEVATORI 23 classi delle specifiche Servlet e JSP sono legate. L ultima colonna della tabella riporta i codici che corrispondono, secondo la numerazione 5 utilizzata dagli sviluppatori di Tomcat, a difetti riconducibili al mancato rispetto della proprietà corrispondente. Nel seguito diamo una descrizione delle proprietà che sono state prese in considerazione durante il lavoro di tesi mostrando come possano essere utilizzate nella specifica di sistemi tramite l annotazione di modelli UML. Le annotazioni che vogliamo rendere disponibili per i nostri modelli si configurano come estensioni del linguaggio di modellazione stesso. UML prevede la possibilità di essere esteso attraverso i Profili. I Profili sono un particolare tipo di diagramma costituito da Stereotipi, degli elementi UML che possono contenere parametri e vincoli, e sono associabili ad entità base del linguaggio UML come classificatori, operazioni, parameteri e relazioni. Gli stereotipi vengono indicati graficamente con il loro nome circondato dai simboli come ad esempio in Language. Per ognuna delle proprietà considerate forniremo una descrizione informale del suo significato ed il suo stereotipo che indica chiaramente quale classe di elementi UML prevediamo possa godere della proprietà. Il profilo che ne risulterà potrà essere utilizzato in un editor UML che rispetti lo standard per facilitare l annotazione di modelli. Ognuna delle proprietà sarà così identificata da uno specifico Stereotipo, il fatto che un elemento di un diagramma UML sia annotato con un certo Stereotipo indicherà allora che il corrispondente oggetto software gode della proprietà corrispondente e che per esso dovrà essere prodotto uno specifico rilevatore che ne monitori il comportamento Proprietà Initialized La proprietà Initialized permette di specificare che un oggetto di una certa classe non può essere utilizzato se non ancora inizializzato dal metodo indicato in uno specifico parametro chiamato Initializer. 5

31 CAPITOLO 3. PROGETTAZIONE DEI RILEVATORI 24 Figura 3.1: Proprietà Initialized: Specifica La figura 3.1 mostra il diagramma in cui si definisce che lo stereotipo Initialized è applicabile alle classi ed ha un parametro Initializer a cui è assegnabile un metodo del modello. Stereotype: Initialized Initializer=init(par : String) Figura 3.2: Proprietà Initialized: Utilizzo La figura 3.2 mostra invece come la proprietà possa essere applicata ad una classe, il digramma indica che la classe MyInitType, e quindi in particolare l attributo s non può essere modificata se prima non è stato eseguito il metodo init() Proprietà Immutable La proprietà Immutable permette di specificare che un oggetto di una certa classe non può essere modificato dopo la sua inizializzazione ad opera

32 CAPITOLO 3. PROGETTAZIONE DEI RILEVATORI 25 di eventuali costruttori. Si tratta di una proprietà la cui utilità è stata molte volte sottolineata anche nell ambito della progettazione di linguaggi di programmazione. Sono state infatti proposte nel passato estensioni per Java che prevedono la possibilità di specificare oggetti immutabili in un senso più esteso rispetto al qualificatore final presente attualmente. La figura 3.3 mostra il profilo corrispondente che è simile al caso precedente tranne che per l assenza di parametri. Figura 3.3: Proprietà Immutable: Specifica Proprietà NotNull La proprietà NotNull permette di specificare che un oggetto non deve essere nullo quando ritornato da un metodo o passato come parametro. L utilizzo di questa proprietà può essere utile in quei linguaggi di programmazione, tra i quali Java, che non prevedono il supporto diretto a tipi non annullabili. La figura 3.4 mostra il diagramma in cui si definisce che lo stereotipo NotNull è applicabile a classi, metodi e parametri di metodi.

33 CAPITOLO 3. PROGETTAZIONE DEI RILEVATORI 26 Figura 3.4: Proprietà NotNull: Specifica Proprietà Language La proprietà Language permette di verificare che una variabile di classe o un parametro appartenga ad un certo linguaggio specificato da una espressione regolare regexp, attributo dello stereotipo Language. La figura 3.5 mostra il diagramma in cui si definisce lo stereotipo Language. Figura 3.5: Proprietà Language: Specifica

34 CAPITOLO 3. PROGETTAZIONE DEI RILEVATORI Proprietà Comparable La proprietà Comparable applicata ad una classe indica che deve essere possibile sapere se due oggetti della classe sono uguali o diversi. Nel caso del linguaggio Java ogni oggetto eredita a questo scopo da Object i metodi equals(object) e hashcode() ma non è necessario che li reimplementi. Lo stereotipo Comparable specifica che un oggetto di quella classe deve implementare direttamente i metodi equals(object) e hashcode() invece di limitarsi ad ereditarli. Il diagramma 3.6 mostra la definizione dello stereotipo Comparable applicabile alle classi. Figura 3.6: Proprietà Comparable: Specifica Proprietà Explicit Realization La proprietà Explicit Realization indica che una classe che realizza una certa interfaccia lo deve fare esplicitamente cioè implementando direttamente tutti i metodi richiesti e non ereditandoli da qualche superclasse. Lo stereotipo explicit estende l elemento UML Realization che corrisponde in Java all implementazione di interfacce.

35 CAPITOLO 3. PROGETTAZIONE DEI RILEVATORI 28 Questa proprietà sebbene probabilmente meno utile delle precedenti in casi reali, dimostra la capacità del metodo di trattare anche modelli di notevole complessità. La sua identificazione è il risultato di una generalizzazione del caso precedente e non dell analisi di malfunzionamenti. Lo stereotipo explicit non può in ogni caso sostituire Comparable perchè in Java non è definita una interfaccia che comprenda i metodi equals(object) e hashcode(), può essere però utilizzato in combinazione con l interfaccia java.lang.comparable. La figura 3.7 mostra il diagramma in cui si definisce lo stereotipo explicit. Figura 3.7: Proprietà Explicit: Specifica Nell esempio riportato in figura 3.8 la classe CompChild eredita da MyCompType ereditandone quindi anche l implementazione del metodo compareto(object) definito in java.lang.comparable, lo stereotipo explicit richiede invece che il metodo compareto sia implementato esplicitamente nella classe CompChild.

36 CAPITOLO 3. PROGETTAZIONE DEI RILEVATORI 29 Package testmodel java.lang.comparable MyCompType attributes operations compareto(o:object):int classes «explicit» CompChild attributes operations classes Figura 3.8: Proprietà Explicit: Utilizo Le ultime due proprietà che abbiamo descritto (Comparable ed Explicit Realization) sono state definite con riferimento specifico al linguaggio di programmazione Java ma sono sufficientemente generali da poter essere ridefinite in modo analogo in qualsiasi linguaggio ad oggetti. 3.2 Sviluppo dei rilevatori Lo sviluppo di un rilevatore per una certa proprietà consisterà delle seguenti fasi: progettazione del rilevatore : in cui si disegna l algoritmo che verifica la proprietà desiderata creazione della trasformazione : in cui si produce il codice che analizzato il modello del sistema genera il rilevatore specifico per la proprietà in esame a partire da un template preparato allo scopo.

37 CAPITOLO 3. PROGETTAZIONE DEI RILEVATORI 30 Il progetto di un rilevatore sarà quindi specifico per la proprietà da rilevare ma consisterà in generale di un template instanziabile con informazioni estratte dal modello del sistema. Quello che accomuna i rilevatori che vogliamo ottenere è però il fatto che essi devono monitorare proprietà strutturali in software ad oggetti, per questo scopo abbiamo identificato nelle nostre ricerche l Aspect Oriented Programming (AOP) come una tecnica adatta alla loro realizzazione. Un programma aspect-oriented è costituito da aspetti ed oggetti in cui gli aspetti sono delle entità esterne che osservano il comportamento degli oggetti e lo modificano quando opportuno, vogliamo usare l AOP per definire quali eventi debbano essere monitorati e quali azioni debbano essere intraprese nel caso un malfunzionamento sia rilevato [9]. Nell AOP l individuazione dei punti di intervento è determinata dai pointcut, un pointcut permette di intercettare in un programma in esecuzione l utilizzo dei costrutti base di un linguaggio ad oggetti come le chiamate di metodi, l accesso a variabili membro e l inizializzazione di oggetti, questi sono proprio gli elementi visibili al livello strutturale dell applicazione ed è per questa ragione che l AOP può essere utilizzata per i nostri scopi.

38 Capitolo 4 Prototipo Questo capitolo descrive l implementazione di un prototipo che permetta la rilevazione dei malfunzionamenti legati alle proprietà elencate nel capitolo precedente secondo la metodologia descritta finora. Come abbiamo già avuto modo di dire, la tecnica risulta particolarmente efficace nel caso sia possibile ottenerne una automatizzazzione il più completa possibile. Nel seguito dimostriamo come, utilizzando alcune tecnologie standard, abbiamo prodotto un catalogo di proprietà e dei relativi generatori di rilevatori il cui utilizzo richiede al progettista soltanto l analisi delle specifiche del sistema e l annotazione del modello della sua struttura. Questo risultato rende completamente automatica la generazione dei rilevatori e la loro messa in opera per le proprietà prese in considerazione. La disponibilità di una implementazione funzionante del metodo ci è infine stata utile per studiare dal vero il comportamento dei rilevatori e raccogliere così informazioni utili a valutarne l efficacia e l applicabilità. 4.1 Tecnologie utilizzate Tra i primi problemi affrontati c è quello dell individuazione di una famiglia di tecnologie che permettesse di portare a termine l intero procedimento. Volendo applicare la nostra tecnica a sistemi scritti in Java ed ottenere uno 31

39 CAPITOLO 4. PROTOTIPO 32 strumento integrato in un ambiente di sviluppo diffuso per facilitarne l adozione, la nostra scelta è caduta su Eclipse, un progetto di software libero ideato da un consorzio di grandi società quali Ericsson, HP, IBM e Intel. Eclipse, grazie alla sua particolare estensibilità, integra molte caratteristiche utili ai nostri scopi, in particolare Eclipse comprende un ambiente di modellazione tra i più avanzati sul mercato chiamato Eclipse Modeling Framework (EMF) su cui baseremo il nostro prototipo per quanto riguarda le fasi di modellazione ed applicazione delle proprietà [24]. Per quanto riguarda invece la realizzazione dei rilevatori di malfunzionamenti ci affideremo ad AspectJ, uno dei più noti tool di AOP anch esso facilmente integrabile in Eclipse. La tabella 4.1 specifica schematicamente quali tecnologie vengono utilizzate per ogni fase del lavoro: Tabella 4.1: Le tecnologie utilizzate Utilizzo Linguaggio di specifica per proprietà Annotazione di modelli Template per i rilevatori Generazione dei rilevatori Applicazione dei rilevatori tecnologia Profili UML2, PDE UML2 XMI, JET, AspectJ JET, PDE LTW di AspectJ Nel seguito descriviamo tali tecnologie e l utilizzo che ne abbiamo fatto UML2 Come ricordato nel capitolo 1 UML è uno tra i più diffusi linguaggi di modellazione, nato con lo scopo di unificare linguaggi preesistenti definisce una notazione semi-grafica e semi-formale per la specifica di sistemi orientati agli oggetti. La standardizzazione di UML è gestita da Object Management Group (OMG) che nelle ultime versioni lo ha reso mano a mano sempre

40 CAPITOLO 4. PROTOTIPO 33 più rigoroso e formale, specialmente per quanto riguarda i suoi meccanismi di estensione. UML2 costituisce una implementazione basata su EMF del metamodello UML 2.x come definito da OMG e si propone di supportare lo sviluppo di strumenti di modellazione all interno della piattaforma di sviluppo Eclipse [11]. La possibilità di estendere UML in modo standard attraverso i Profili consente di sfruttare la sua enorme diffusione e popolarità per creare dei Domain Specific Language (DSL) facilmente adottabili in progetti reali. I profili sono composti da stereotipi che possono a loro volta contenere parametri e vincoli, questi stereotipi sono applicati ad elementi base del linguaggio UML e ne estendono le funzionalità Il tool che abbiamo prodotto permette la specifica su modelli UML preesistenti delle proprietà volute, per il suo utilizzo non è richiesta la modellazione completa del sistema ma soltanto di quelle parti su cui tali proprietà sono applicate. OMG definisce una codifica XML standard chiamata XML Metadata Interchange (XMI) che può essere utilizzata per serializzare modelli UML, questo standard garantisce l interoperabilità tra strumenti di sviluppo diversi [27]. Le analisi che il nostro prodotto effettua sui modelli vengono operate a livello di XMI, questo fatto garantisce la compatibilità con modelli creati al di fuori di Eclipse rendendolo di fatto utilizzabile con qualunque ambiente di modellazione supporti una versione sufficientemente recente dello standard UML JET JET è un generatore di codice che permette di istanziare un template prodotto allo scopo con dati variabili estratti da un modello espresso in Extensible Markup Language (XML). JET fornisce comandi specifici per la produzione di template molto espressivi ed è inoltre facilmente estendibile in Java, l utilizzo di JET facilita il recupero di informazioni all interno di un

41 CAPITOLO 4. PROTOTIPO 34 documento XML mettendo a disposizione selettori e funzioni XPath 1. Nel nostro tool utilizziamo JET per l analisi dei modelli UML, per l estrazione delle informazioni necessarie e per il loro inserimento in rilevatori generici. Questa fase del progetto si è rivelata tra le più difficili a causa della ricchezza espressiva di UML e della conseguente complessità dell analisi dei file XMI AspectJ AspectJ 2 è un linguaggio basato su Java per la creazione di aspetti che possono essere combinati a compile-time oppure a load-time con codice Java esistente. AspectJ permette di definire due tipi di elementi: Pointcut: è una condizione che può essere verificata o meno in ogni momento dell esecuzione del programma target, è costruito componendo costrutti elementari detti Join Point che intercettato l esecuzione dei meccanismi base del linguaggio di programmazione (chiamate di metodi, accesso a variabili membro...) Advice: contiene il codice che deve essere eseguito quando un certo Pointcut diventa valido. AspectJ è uno degli strumenti più utilizzati in ambito AOP, il suo supporto per il Load Time Weaving (LTW) ci permette di combinare gli aspetti prodotti dal nostro tool con sistemi esistenti anche senza la disponibiltà del relativo codice sorgente conferendogli così ulteriore agilità. Inoltre gli aspetti verranno applicati anche nel caso di classi generate dinamicamente dal sistema. 1 XPath: 2 AspectJ:

42 CAPITOLO 4. PROTOTIPO Eclipse Plug-in Development Il Plug-in Development Environment (PDE) è parte dell Eclipse Standard Development Toolkit (SDK) e fornisce strumenti per creare, testare e mettere in opera componenti aggiuntivi per l ambiente di sviluppo. Il supporto alla modellazione delle proprietà desiderate ed alla creazione di rilevatori opportuni è stato ottenuta attraverso la produzione di opportuni plug-in per Eclipse. 4.2 L Implementazione Per ognuna delle proprietà descritte nel capitolo 3 descriviamo il rilevatore prodotto e la trasformazione che lo produce, per capire il funzionamento della trasformazione sarà spesso necessario rifarsi alla serializzazione XMI del modello il cui formato verrà chiarito nei suoi tratti più salienti. Il codice completo per le trasformazioni esaminate è riportato nell appendice A Linguaggio di specifica Per prima cosa abbiamo ottenuto il linguaggio di specifica delle nostre proprietà attraverso la realizzazione di un profilo UML. I diagrammi riportati nel capitolo 3 rappresentano i diversi stereotipi che compongono il profilo. Perchè questo profilo possa essere utilizzato per annotare modelli UML esso deve essere reso disponibile all interno dell ambiente di lavoro di Eclipse, bisogna cioè creare un plugin per Eclipse che specifici i parametri richiesti dagli extension point di interesse. La definizione seguente rende disponibile il profilo UML propcheck specificandone il percorso relativo nel filesystem attraverso l extension point org.eclipse.emf.ecore.uri mapping 1 < extension profilo propcheck: plugin.xml

43 CAPITOLO 4. PROTOTIPO 36 2 point =" org. eclipse. emf. ecore. uri_mapping "> 3 < mapping source =" pathmap: // PROPCHECK_PROFILES /" 4 target =" platform: / plugin / propcheck / model /"> 5 </ mapping > 6 </ extension > 7 8 < extension 9 point =" org. eclipse. uml2. uml. dynamic_package "> 10 < profile uri =" propcheck " 11 location =" pathmap: // PROPCHECK_PROFILES / profile. uml "> 12 </ profile > 13 </ extension > Una procedura guidata fornita da Eclipse permette di ottenere da essa un plugin immediatamente utilizzabile La trasformazione del modello Nella sua rappresentazione XMI ogni elemento di un modello UML è identificabile attraverso il parametro xmi:id. L applicazione di uno stereotipo ad un elemento si riduce quindi ad una semplice dichiarazione in cui è indicato il nome dello stereotipo, l id della sua applicazione, l id dell elemento annotato e gli eventuali parametri della proprietà. Riportiamo il caso dello stereotipo Language che dimostra il formato completo richiedendo un espressione regolare come parametro: 1 < propcheck:language applicazione di uno stereotipo 2 xmi:id =" _bh9m0nf - Ed29yvx8hNN9SQ " 3 base_parameter =" _g8_kw9czed2xdmaq04cwha " 4 regexp ="[\p{ Print }&\ p{ ASCII }]* "/> La trasformazione nel suo complesso sarà governata da un template main.jet che per ognuno degli stereotipi applicati analizzerà il modello alla ricerca degli elementi coinvolti e richiamerà la trasformazione specifica per quella proprietà salvando il risultato in un file AspectJ. Il codice seguente dimostra la procedura nel caso in cui stereotipo Language sia applicato ad un parametro di metodo:

44 CAPITOLO 4. PROTOTIPO 37 trasformazione main.jet 1 < c:iterate select ="/ XMI / Language " 2 var =" parid "> 3 < c:setvariable select ="$ parid /.. " var =" language "/> 4 <% -- extracting the regexp --% > 5 < c:setvariable select =" $ language " 6 var =" regexp "/> 7 <c:if test =" count ($ regexp ) = 0"> 8 < c:setvariable select =".* " var =" regexp "/> 9 </ c:if > 10 <% -- finding the affected parameter --% > 11 < c:setvariable select ="// ownedparameter =$ parid ]" 12 var =" par "/> 13 < c:setvariable select ="$ par " var =" parname "/> 14 <% -- finding the containing operation --% > 15 < c:setvariable select ="$ par /.. " var ="op"/> 16 < c:setvariable select " var =" opname "/> 17 <% -- finding the containing class --% > 18 < c:setvariable select ="$op /.. " var =" class "/> < c:setvariable select =" class " var =" classvar "/> 21 < c:include template =" templates / setclasspackage. jet "/> 22 < ws:folder path ="{$ classfoldername }"> 23 < ws:file template =" templates / Language.aj.jet " 24 path ="{$ classfilename }_{$ opname }_{$ parname } _Language.aj" /> 25 </ ws:folder > 26 </ c:iterate > Il template mostrato funziona nel modo seguente: linee 1-6 viene eseguito un ciclo che per ogni applicazione dello stereotipo Language registra l id del parametro annotato ($parid) e l espressione regolare ($regexp) linee 7-9 nel caso l espressione regolare non sia indicata utilizza l espressione generica.* linee trova nel modello l elemento che rappresenta il parametro annotato ($par) e ne identifica il nome ($parname)

45 CAPITOLO 4. PROTOTIPO 38 linee trova nel modello il metodo che accetta il parametro annotato ($op) e ne identifica il nome ($opname) linea 18 trova nel modello la classe che espone il metodo $op linee esegue la trasformazione setclasspackage.jet per ottenere il nome completo della classe, il suo funzionamento viene spiegato nel seguito linee esegue il template Language.aj.jet e ne salva il risultato in un file dal nome univoco ricavato dalla segnatura del parametro annotato Alcune limitazioni dello strumento JET come l impossibilità di parametrizzare i template e la presenza esclusiva di variabili globali e quindi visibili da ogni trasformazione richiamata da main.jet possono essere aggirate abbastanza agevolmente grazie alla capacità di JET di includere codice espresso direttamente in Java, un caso in cui abbiamo sfruttato questa possibilità è stato nella realizzazione della trasformazione setclasspackage.jet. Questa trasformazione prende in considerazione la variabile $classvar contenete il nome della variabile che punta nel modello UML alla classe sotto esame. Nel caso precedente tale nome è proprio class. A questo punto la trasformazione ricava il nome completo, considerando anche il caso di Package e Classi innestate, della classe riferita da $class. Il codice JET per questa trasformazione è complicato dalla necessità di aggirare le suddette limitazioni. La trasformazione analizza ricorsivamente la gerarchia delle classi e dei package e ne scrive il nome completo rispettivamente nelle variabili $classname $classpackagename dove class è rimpiazzato dal contenuto di $classvar. La trasformazione main.jet descritta finora viene ripetuta in maniera molto simile per tutti gli altri stereotipi. Nel caso ci siano differenze rilevanti saranno evidenziate nelle sezioni dedicate ad ognuno di loro nel seguito del capitolo in cui verrà anche descritta la trasformazione specifica che genera i rilevatori AspectJ.

46 CAPITOLO 4. PROTOTIPO Rilevatore per Initialized La proprietà Initialized permette di specificare che un oggetto di una certa classe non può essere utilizzato se nullo o non ancora inizializzato tramite un metodo specifico. Analizziamo questo rilevatore con particolare dettaglio in particolare per quanto riguarda le caratteristiche comuni a tutti gli altri. Il seguente codice XMI (semplificato) corrisponde al diagramma delle classi mostrato nella Figura 3.1b del capitolo 3 che modella la classe MyInitType ed il suo metodo init: 1 < uml:model... > initialize.uml 2 < packagedelement xmi:type =" uml:package "... > 3 < packagedelement xmi:id =" _zs97ujcped26upwym4f5zg " 4 xmi:type =" uml:class " name =" MyInitType "> 5 < ownedattribute name ="s">... </ ownedattribute > 6 < ownedoperation name =" init " 7 xmi:id =" _YLGFQJCQEd26upWYm4f5zg "> 8 < ownedparameter name =" par ">... </ ownedparameter > 9 </ ownedoperation > 10 </ packagedelement > 11 </ packagedelement > 12 </ uml:model > Alla classe MyInitType è applicato lo stereotipo Initialized con parametro l identificatore xmi:id corrispondente al metodo init: initialize.uml 1 < propcheck:initialized 2 xmi:id =" _ms4f8kw0ed2pepbvoy45wa " 3 base_class =" _zs97ujcped26upwym4f5zg " 4 Initializer =" _YLGFQJCQEd26upWYm4f5zg "/> Quello che vogliamo ottenere dalla trasformazione sono due aspetti AspectJ per ognuna delle annotazioni: MyInitType Initialized.aj

47 CAPITOLO 4. PROTOTIPO 40 1 public aspect MyInitType_Initialized pertarget ( target ( MyInitType )){ 2 // A boolean variable local to the aspect 3 private boolean initialized = false ; 4 5 // Matches methods allowed to initialize the object 6 // Marks the object as initialized 7 pointcut initmethods (): call (* testmodel. MyInitType. init (..) ); 8 after () returning :! cflow ( adviceexecution ()) 9 && target ( MyInitType ) && initmethods (){ 10 initialized = true ; 11 } // Matches any non - initializing method 14 // Checks if the target object is initialized 15 pointcut noninitmethods (): 16! call (* MyInitType. getclass (..) ) 17 &&! cflow ( initmethods ()) 18 &&! cflow ( call ( MyInitType. new (..) )) 19 && call (* MyInitType.*(..) ); 20 before ():! cflow ( adviceexecution ()) 21 && noninitmethods () { 22 if (! initialized ){ 23 Logger. getlogger ("... "). log ( Level. SEVERE, 24 " Accessing a non Initialized object of type MyInitType ", 25 new Throwable ()); 26 } 27 } 28 } Questo primo aspetto verifica che non sia possibile utilizzare metodi di MyInitType prima di init modificando adeguatamente la variabile initialized (linea 10). Prima dell esecuzione di qualunque metodo (linee 19-21) che non sia l inizializzatore (linee 7 e 17) od un costruttore (linea 18), l aspetto verificherà lo stato della variabile initialized rilevando così tutti i casi in cui la proprietà non sia rispettata e notificando il malfunzionamento inserendo una voce dettagliata nei log del sistema (linee 23-25). Il secondo aspetto ottiene il medesimo risultato nel caso si stia cercando

48 CAPITOLO 4. PROTOTIPO 41 di chiamare metodi su un oggetto nullo (linea 5): MyInitType NotNullInitialized.aj 1 public aspect MyInitType_NotNullInitialized { 2 // Checks if an object is Null when target 3 before ( Object t):! cflow ( adviceexecution ()) 4 && noninitmethods () && target (t) 5 && if (t== null ){ 6 Logger. getlogger ("... "). log ( Level. SEVERE, 7 " Accessing a Null object of type MyInitType ", 8 new Throwable ()); 9 } 10 } L ultimo passo per ottenere un rilevatore funzionante consiste nel disegno della trasformazioni Initialized.aj.jet e NotNullInitialized.aj.jet che generino i rilevatori appena mostrati utilizzando le informazioni estratte dal modello durante l esecuzione di main.jet. Queste trasformazioni costituiscono un template generico dei rilevatori indipendente dal particolare modello in esame. Di seguito riportiamo alcuni estratti dal codice JET che mostrano come il modello viene trasformato in codice AspectJ: 1 <% -- --%> Initialized.aj.jet 2 <% // generating the corresponding aspect in aop. xml 3 String aop = context. getvariable (" aopxml "). tostring (); 4 aop = aop. concat ("<aspect name =\""). concat ( context. getvariable (" classpackagename "). tostring ()); 5 aop = aop. concat (". aspects."). concat ( context. getvariable (" classfilename "). tostring ()); 6 context. setvariable (" aopxml ",aop. concat (" _Initialized \" / >\n")); 7 %> 8 < c:replacestrings 9 replace ="% class,% package " 10 with ="{$ classname },{$ classpackagename }">

49 CAPITOLO 4. PROTOTIPO </ c:replacestrings > Ogni trasformazione dovrà come primo compito popolare il file aop.xml con le informazioni relative all aspetto AspectJ generato, questo è necessario ai fini di poter utilizzare le caratteristiche di LTW di AspectJ. Le linee 1-7 del listato infatti aggiungono nel file aop.xml la riga <aspect name="testmodel.aspects.myinittype_initialized"/> Il resto della trasformazione (linee 8-14) sostituisce il nome della classe (MyInitType) e quando necessario del metodo inizializzatore (init) nei punti opportuni trasformando ad esempio il template pointcut initmethod(): target(%class) <c:if test="count($op) > 0"> && call(* <c:get select="$opclasspackagename" />.<c:get select="$opclassname" />.<c:get select="$opname" />(..))</c:if>; nel codice pointcut initmethods(): call(* testmodel.myinittype.init(..)); Rilevatore per Immutable La proprietà Immutable permette di specificare che un oggetto di una certa classe non può essere modificato dopo la sua costruzione. Il suo profilo UML e la trasformazione che genera il codice eseguibile sono molo simili al caso precedente, di seguito mostriamo un estratto del template JET: Immutable.aj.jet 1 before ():! cflow ( adviceexecution ()) 2 && set (* % class.*) 3 &&! cflow ( call (% class. new (..) )){

50 CAPITOLO 4. PROTOTIPO 43 4 Logger. getlogger ("ch. unisi. inf. luminous "). log ( Level. SEVERE, 5 " Modifying an << Immutable > > Object of type % class ", 6 new Throwable ()); 7 } Prima di permettere l accesso in scrittura ad un attributo della classe annotata (linee 1-2) l aspetto di assicura di trovarsi nel flusso di controllo di un costruttore (linea 3) ed in caso contrario registra un avverimento nei log del sistema (linee 4-6) Rilevatore per NotNull Lo stereotipo NotNull permette di specificare che certi oggetti no debbano essere nulli quando ritornati da un metodo o passati come parametro. Il diagramma 4.1 mostra la classe MyNotNullReturn in cui il metodo next() è stato annotato con lo stereotipo NotNull e la classe MyLanguage nella quale il parametro subject del metodo send () riporta la stessa annotazione. Package testmodel MyNotNullReturn attributes operations «NotNull» next():object classes MyLanguage attributes operations send («language»address:string, «NotNull»subject:String) classes Figura 4.1: Applicazione NotNull

51 CAPITOLO 4. PROTOTIPO 44 1 < xmi:xmi... > NotNull.uml 2 < uml:model... name =" tests "> 3 < packagedelement... name =" testmodel " > 4 < packagedelement xmi:type =" uml:class " 5... name =" MyLanguage "> 6 < ownedoperation... name =" send " > 7 < ownedparameter xmi:id =" _g8_kwdczed2xdmaq04cwha " 8... name =" address "/> 9 < ownedparameter xmi:id =" _g8_kwtczed2xdmaq04cwha " name =" subject "/> 11 </ ownedoperation > 12 </ packagedelement > < packagedelement xmi:type =" uml:class " name =" MyNotNullReturn "> 16 < ownedoperation xmi:id =" _AkBC4Nc0Ed2xdMAQ04CwHA " name =" next "> 18 < ownedparameter... name =" return " 19 direction =" return "/> 20 </ ownedoperation > 21 </ packagedelement > 22 </ packagedelement > 23 </ uml:model > 24 < propcheck:notnull xmi:id =" _KlTIQNf9Ed29yvx8hNN9SQ " 25 base_parameter =" _g8_kwtczed2xdmaq04cwha "/> 26 < propcheck:notnull xmi:id =" _DvQWINgAEd29yvx8hNN9SQ " 27 base_operation =" _AkBC4Nc0Ed2xdMAQ04CwHA "/> 28 </ xmi:xmi > L estratto XMI mostrato corrisponde al diagramma delle classi in Figura 4.1 in cui lo stereotipo NotNull (linee 26-27) è applicato al metodo next (linee 16-17) ed al parametro subject (linee e 8-9). Nel primo caso la trasformazione dovrà controllare che il valore di ritorno del metodo next() non sia nullo: NotNullReturn.aj.jet 1 after () returning ( Object retval ):! cflow ( adviceexecution ()) 2 && call (* *.% operation (..) ) && target (% class ){ 3 if( retval == null ){

52 CAPITOLO 4. PROTOTIPO 45 4 Logger. getlogger ("ch. unisi. inf. luminous "). log ( Level. SEVERE, 5 " Null object returned calling % class.% operation ", 6 new Throwable ()); 7 } 8 } La trasformazione mostrata genera un aspetto che esegue il metodo annotato (linea 2) e ne memorizza il valore di ritorno nella variabile retval (linea 1), nel caso esso risulti nullo notifica il malfunzionamento (linee 4-7). Il secondo caso è invece più complesso: NotNullParameter.aj.jet 1 before (<c:iterate select ="$op/ ownedparameter " 2 var =" par " delimiter =", ">Object 3 <c:get select ="$ par " /> 4 </ c:iterate >): call (* 5 <c:get select ="$ classname "/> 6.<c:get select ="$ opname "/>(..) ) 7 && args (<c:iterate 8 select ="$op/ ownedparameter " 9 var =" par " delimiter =", "><c:get select ="$ par " /> 10 </ c:iterate >){ 11 if (<c:get select ="$ parname "/>== null ){ 12 Logger. getlogger ("ch. unisi. inf. luminous "). log ( Level. SEVERE, 13 " Null value detected for parameter named < c: get select ="$ parname "/>", 14 new Throwable ()); 15 } 16 } La trasformazione dovrà analizzare il modello UML per estrarre la segnatura del metodo che accetta il parametro annotato. In particolare deve iterare (linee 1-10) sui parametri del metodo coinvolto (linee 7-10 del modello UML) per leggerne i nomi e successivamente, nel caso il parametro annotato sia nullo, notificare il malfunzionamento (linee 11-14). L aspetto prodotto da questa seconda trasformazione applicata al modello presentato nelle pagine precedenti sarà il seguente:

53 CAPITOLO 4. PROTOTIPO 46 MyLanguage send subject NotNullParameter.aj 1 public aspect MyLanguage_send _subject_NotNullParameter { 2 before ( Object address, Object subject ): 3 call (* MyLanguage. send (..) ) 4 && args ( address, subject ){ 5 if ( subject == null ){ 6 Logger. getlogger ("ch. unisi. inf. luminous "). log ( Level. SEVERE, 7 " Null value detected for parameter named subject ", 8 new Throwable ()); 9 } 10 } 11 } L aspetto cattura (linea 4) i parametri del metodo send e controlla prima della sua esecuzione (linee 2-3) che il parametro subject non sia nullo (linea 5) Rilevatore per Language La proprietà Language permette di verificare che una variabile di classe o un parametro appartenga ad un certo linguaggio specificato da una espressione regolare regexp, attributo dello stereotipo Language. Nella figura 4.1 utilizzata nella sezione precedente, lo stereotipo Language è applicato al parametro address del metodo send . Il codice XMI corrispondente dovrà allora contenere anche la dichiarazione seguente che indica, usando la sintassi di Java, l espressione regolare attraverso la quale il parametro address può essere riconosciuto come un indirizzo valido: <propcheck:language xmi:id="_xxnjinf-ed29yvx8hnn9sq" base_parameter="_g8_kwdczed2xdmaq04cwha" regexp= "^[a-za-z0-9._%+-]+@[a-za-z0-9.-]+\.[a-za-z]{2,4}$"/> La trasformazione che genere il rilevatore per questa proprietà estrarrà

54 CAPITOLO 4. PROTOTIPO 47 la segnatura del metodo coinvolto esattamente come nel caso precedente, riportiamo di seguito la seconda parte del template JET: Language.aj.jet 1 <% -- in the regexp backslashes are escaped --% > 2 if (<c:get select ="$ parname "/>== null 3!<c:get select ="$ parname "/>. tostring (). matches ( 4 "<f:replaceall value ="\\" replacement =" \\\\ "> 5 <c:get select ="$ regexp "/> 6 </ f:replaceall >")){ 7 Logger. getlogger ("ch. unisi. inf. luminous "). log ( Level. SEVERE, 8 " Language mismatch for parameter named < c: get select = "$ parname "/>", 9 new Throwable ()); 10 } La trasformazione converte il parametro annotato in una stringa di testo (linea 3) utilizzando il metodo tostring() disponibile per ogni oggetto Java, sucessivamente utilizza su di esso il metodo matches(string) che lo confronta con l espressione regolare formattata adeguatamente (linee 3-6), il carattere \ è infatti un carattere speciale che deve perciò essere raddoppiato. MyLanguage send address Language.aj 1 public aspect MyLanguage_send _address_Language { 2 // Checks if a parameter matches a given regexp 3 before ( Object address, Object subject ): 4 call (* MyLanguage. send (..) ) 5 && args ( address, subject ){ 6 if (! address. tostring (). matches (" 7 ^[a-za -Z0-9. _ %+ -Z0-9. -]+\\.[a-za -Z ]{2,4} $")){ 8 Logger. getlogger ("ch. unisi. inf. luminous "). log ( Level. SEVERE, 9 " Language mismatch for parameter named address ", 10 new Throwable ()); 11 } 12 } 13 }

55 CAPITOLO 4. PROTOTIPO 48 Il codice AspectJ generato verifica, prima di ogni chiamata del metodo estratto dal modello (linee 3-5), la corrispondenza tra il parametro annotato e l espressione regolare fornita (linee 6-7). Notifica il sistema in caso la proprietà non sia rispettata Rilevatore per Comparable Lo stereotipo Comparable specifica che un oggetto di una certa classe deve implementare direttamente i metodi equals() e hashcode() di java.lang.object invece di limitarsi ad ereditarli. La sua applicazione ad un elemento del modello viene specificata attraverso la seguente dichiarazione che riporta nell attributo base Class l identificativo della classe da monitorare. <propcheck:comparable xmi:id="_f2gjon20ed2rulnlwi0toa" base_class="_xpgiwnczed2xdmaq04cwha"/> Il rilevatore per questa proprietà utilizza le capacità di Reflection fornite da Java: Comparable.aj.jet 1 after ():! cflow ( adviceexecution ()) && 2 staticinitialization (<c:get select ="$ classname "/>){ 3 try { 4 <c:get select ="$ classname " />. class 5. getdeclaredmethod (" hashcode ",new Class [] {}) ; 6 } 7 catch ( NoSuchMethodException e) { 8 Logger. getlogger ("ch. unisi. inf. luminous "). log ( Level. SEVERE, 9 "<c:get select ="$ classname "/> doesn t implement 10 the method \" hashcode ()\" directly ", 11 new Throwable ()); 12 } 13 try { 14 <c:get select ="$ classname " />. class 15. getdeclaredmethod (" equals ",

56 CAPITOLO 4. PROTOTIPO new Class [] { Object. class }); 17 } 18 catch ( NoSuchMethodException e) { 19 Logger. getlogger ("ch. unisi. inf. luminous "). log ( Level. SEVERE, 20 "<c:get select ="$ classname "/> doesn t implement 21 the method \" equals ( Object )\" directly ", 22 new Throwable ()); 23 } 24 } In particolare analizzando gli oggetti della classe annotata dopo la loro inizializzazione (linee 1-2), il rilevatore utilizza il metodo getdeclaredmethod() per sapere se equals() e hashcode() siano implementati direttamente (linee 4-5 e 14-16), in caso contrario notifica al sistema il mancato rispetto della proprietà (linee 7-12 e 18-23) Rilevatore per Explicit Realization Lo stereotipo explicit estende l elemento UML Realization che corrisponde in Java all implementazione di interfacce. Una classe che implementa in maniera explicit un interfaccia deve implementare direttamente tutti i suoi metodi e non può utilizzare implementazioni ereditate da superclassi. Riprendendo l esempio modellato nel capitolo 3 riportiamo un estratto della codifica XMI del diagramma < xmi:xmi... > explicit.uml 2 < uml:model... name =" tests "> 3 < packagedelement xmi:type =" uml:package " 4 name =" testmodel "> 5 6 < packagedelement xmi:type =" uml:class " 7 name =" MyCompType " 8 xmi:id =" _blcwqncxed2xdmaq04cwha " 9 clientdependency =" _GGaEkN2vEd2RuLnlWI0TOA "> 10 < interfacerealization

57 CAPITOLO 4. PROTOTIPO client =" _blcwqncxed2xdmaq04cwha " contract =" _COr04Nf4Ed29yvx8hNN9SQ "/> 13 < ownedoperation... name =" compareto " > </ ownedoperation > 16 </ packagedelement > < packagedelement name =" CompChild " xmi:id =" _S_qwwNcyEd2xdMAQ04CwHA " 20 clientdependency =" _PAaLIN2vEd2RuLnlWI0TOA "> 21 < generalization xmi:id ="_XO - p0ncyed2xdmaq04cwha " 22 general =" _blcwqncxed2xdmaq04cwha "/> 23 < interfacerealization 24 xmi:id =" _PAaLIN2vEd2RuLnlWI0TOA " client =" _S_qwwNcyEd2xdMAQ04CwHA " 26 contract =" _COr04Nf4Ed29yvx8hNN9SQ "/> 27 </ packagedelement > 28 </ packagedelement > < packagedelement xmi:type =" uml:package " name =" java "> 32 < packagedelement xmi:type =" uml:package " name =" lang "> 34 < packagedelement xmi:type =" uml:interface " 35 name =" Comparable " 36 xmi:id =" _COr04Nf4Ed29yvx8hNN9SQ "> 37 < ownedoperation... name =" compareto " > </ ownedoperation > 40 </ packagedelement > 41 </ packagedelement > 42 </ packagedelement > 43 </ uml:model > < propcheck:explicit 46 xmi:id =" _u2t60n2xed2rulnlwi0toa " 47 base_realization =" _PAaLIN2vEd2RuLnlWI0TOA "/> 48 </ xmi:xmi > Nel modello possiamo identificare i seguenti elementi linee Modellazione dell interfaccia java.lang.comparable con il suo metodo compareto(object)

58 CAPITOLO 4. PROTOTIPO 51 linee 6-16 La classe MyCompType realizza l interfaccia Comparable come indicato alla linea 12 dall attributo contract. MyCompType implementa il metodo compareto(object) (linee 13-15) come richiesto dal linguaggio Java nel caso di implementazione di interfacce. linee La classe CompChild eredita da CompType (linee attributo general) ed implementa anch essa l interfaccia Comparable (linee attributo contract) linee L applicazione dello stereotipo explicit fa riferimento attraverso l attributo base Realization al codice identificativo della relazione tra CompChild e Comparable (linee 23-26) che risulta quindi annotata dalla proprietà. Analizziamo ora la trasformazione che genera il rilevatore per il mancato rispetto di questa proprietà. La sezione della trasformazione main.jet dedicata ad explicit diversa dalle precedenti: main.jet 1 <% -- finding the InterfaceRealization --%> 2 < c:setvariable 3 select ="// interfacerealization =$ realid ]" 4 var =" realization "/> 5 6 <% -- finding the affected Class --% > 7 < c:setvariable 8 select ="// packagedelement =$ realization ]" 9 var =" class "/> < c:setvariable 12 select =" class " var =" classvar "/> 13 < c:include template =" templates / setclasspackage. jet "/> <% -- finding the implemented Interface --% > 16 < c:setvariable 17 select ="// packagedelement =$ realization ]" 18 var =" interface "/> 19 sarà

59 CAPITOLO 4. PROTOTIPO < c:setvariable 21 select =" interface " var =" classvar "/> 22 < c:include template =" templates / setclasspackage. jet "/> Per ognuna delle applicazioni dello stereotipo explicit modello, la trasformazione si comporterà come segue: presente nel linee 2-4 Identifica nel modello XMI le relazioni annotate. linee 7-9 Localizza la classe coinvolta nella relazione attraverso l identificativo contenuto nell attributo client linee Utilizza il template setclasspackage per ottenere la segnatura completa della classe e del suo package che nel caso saranno salvati nelle variabili classname e classpackagename linee Localizza la classe coinvolta nella relazione attraverso l identificativo contenuto nell attributo contract linee Utilizza il template setclasspackage per ottenere la segnatura completa dell interfaccia classe e del suo package che saranno salvati nelle variabili interfacename e interfacespackagename A questo punto viene richiamata la trasformazione explicit.aj.jet che genera l aspetto AspectJ voluto: explicit.aj.jet 1 after ():! cflow ( adviceexecution ()) 2 && staticinitialization (% package.% class ){ 3 Class <?> aclass =% package.% class. class ; 4 Class <? > aninterface =% intpackage.% interface. class ; 5 6 // aclass implements directly all the methods 7 // declared in aninterface 8 for ( Method m: aninterface. getdeclaredmethods ()){ 9 try { 10 aclass. getdeclaredmethod (m. getname (), 11 m. getparametertypes ()); 12 } 13 catch ( NoSuchMethodException e) {

60 CAPITOLO 4. PROTOTIPO Logger. getlogger ("ch. unisi. inf. luminous "). log ( Level. SEVERE, 15 "% package.% class."+m. getname ()+ 16 " is not implemented explicitly ", 17 new Throwable ()); 18 } 19 } 20 } linee 1-2 Vengono individuati a run-time i tipi della classe e dell interfaccia coinvolti nella relazione annotata con explicit. linee 8-12 Per ognuno dei metodi definiti nell interfaccia si verifica che questo sia implementato direttamente dalla classe utilizzando il metodo getdeclaremethod(). linee Nel caso la proprietà non risulti verificata si genera una notifica adatta che riporta il nome del metodo mancante. Il rilevatore generato per il modello descritto dalla figura 3.8 sarà dunque il seguente: CompChild implements Comparable explicitly.aj 1 import java. lang. reflect. Method ; 2 import java. util. logging.*; 3 4 public aspect CompChild_implements_Comparable_explicitly { 5 after ():! cflow ( adviceexecution ()) && 6 staticinitialization ( testmodel. CompChild ){ 7 Class <? > aclass = testmodel. CompChild. class ; 8 Class <? > aninterface = java. lang. Comparable. class ; 9 10 // aclass implements directly all the methods 11 // declared in aninterface 12 for ( Method m: aninterface. getdeclaredmethods ()){ 13 try { 14 aclass. getdeclaredmethod (m. getname (), 15 m. getparametertypes ()); 16 } 17 catch ( NoSuchMethodException e) {

61 CAPITOLO 4. PROTOTIPO Logger. getlogger ("ch. unisi. inf. luminous "). log ( Level. SEVERE, 19 " testmodel. CompChild."+m. getname ()+ 20 " is not implemented explicitly ", 21 new Throwable ()); 22 } 23 } 24 } 25 } Utilizzare trasformazioni in Eclipse Nell ottica di rendere l utilizzo della tecnica il più semplice possibile, vogliamo che la trasformazione descritta nelle sezioni precedenti possa essere applicata a modelli UML presenti all interno dell ambiente di lavoro Eclipse con un solo click del mouse. Abbiamo perciò prodotto, utilizzando il supporto specifico offerto da Eclipse tramite PDE, un plugin che aggiunge la nostra trasformazione a quelle già presenti. Il plugin è definito in un seguente file XML: 1 < extension 2 id="" trasformazione uml2aj: plugin.xml 3 point =" org. eclipse. jet. transform "> 4 < transform 5 modelextension =" xml " 6 modelloader =" org. eclipse. jet. emfxml " 7 starttemplate =" templates / main. jet " 8 templateloaderclass =" uml2aj. compiled. _jet_transformation "> 9 < description > </ description > 10 < taglibraries > 11 < importlibrary id=" org. eclipse. jet. controltags " 12 useprefix ="c" autoimport =" true "/> 13 < importlibrary id=" org. eclipse. jet. javatags " 14 useprefix =" java " autoimport =" true "/> 15 < importlibrary id=" org. eclipse. jet. formattags " 16 useprefix ="f" autoimport =" true "/> 17 < importlibrary id=" org. eclipse. jet. workspacetags "

62 CAPITOLO 4. PROTOTIPO useprefix ="ws" autoimport =" false "/> 19 </ taglibraries > 20 </ transform > 21 </ extension > La procedura di esportazione fornita da PDE produce un singolo file jar che può essere copiato nella cartella dropins di Eclipse, al successivo riavvio del ambiente di sviluppo la trasformazione sarà disponibile per ogni modello UML. Una semplice configurazione (figura 4.2) permette di generare automaticamente dal modello tutti i rilevatori di malfunzionamenti richiesti. Figura 4.2: Configurazione della trasformazione in Eclipse 4.3 Difficoltà incontrate La realizzazione del prototipo descritto precedentemente è stata notevolmente complicata dal fatto che gran parte degli strumenti utilizzati sono ancora in fase di sviluppo e perciò non ancora del tutto adatti per l utilizzo in produzione. La scelta di strumenti a modello di sviluppo aperto ha permesso di superare queste difficoltà grazie al supporto ottenuto dai team di sviluppo, la

63 CAPITOLO 4. PROTOTIPO 56 costruzione del prototipo ha evidenziato infatti alcuni difetti che sono stati segnalati e discussi con gli sviluppatori durante il periodo della tesi, in particolare in JET, UML2 3 e AspectJ 45. La scelta stessa di quali strumenti fossero i più adatti non è stata automatica visto che possono essere immaginate molte altre strade per ottenere gli stessi risultati, in particolare è stata presa in considerazione la possibilità di definire un linguaggio di modellazione testuale specifico per il nostro dominio di applicazione anzichè utilizzare le possibilità di estensione offerte da UML. Anche l utilizzo della AOP per i rilevatori non è stata l unica possibilità presa in considerazione, sarebbe probabilmente stato possibile ottenere risultati simili utilizzando linguaggi dinamici compatibili con Java come ad esempio Groovie o Jython. Di altra natura invece le difficoltà incontrate nella progettazione dei rilevatori, la potenza espressiva della programmazione orientata agli aspetti va di pari passo con una certa pericolosità, è infatti molto facile interferire nel codice esistente in modo da comprometterne le funzionalità. Particolare attenzione è stata messa nella produzione di aspetti che non modifichino il comportamento delle classi su cui agiscono se non per il minimo necessario

64 Capitolo 5 Risultati sperimentali Il funzionamento della libreria di aspetti descritta nel capitolo precedente è stato verificato estensivamente attraverso una batteria di test che copre un ampio spettro di situazione di utilizzo possibili. I risultati ottenuti hanno permesso di correggere alcuni difetti individuati e di ottenere in ultima analisi un prodotto qualitativamente soddisfacente. In una seconda fase abbiamo modellato ed annotato alcune parti della specifica JSP. Dal modello prodotto abbiamo generato i rilevatori AspectJ per alcuni malfunzionamenti noti in Tomcat ed osservato il loro effettivo rilevamento a run-time. 5.1 Test Per poter ottenere dei rilevatori testabili, il primo passo necessario è modellare un insieme di classi Java a cui poter applicare le proprietà a disposizione. Queste classi dovranno anche esibire un comportamento, per quanto semplice, che permetta di osservare il rispetto o meno di tali proprietà. L intera fase è stata portata a termine a livello di modellazione. L utilizzo del plugin di Eclipse Papyrus 1 (figura 5.1) in accoppiata con il generatore di

65 CAPITOLO 5. RISULTATI SPERIMENTALI 58 codice Acceleo 2 ha permesso di modellare le classi necessarie e di generarne l implementazione Java. Figura 5.1: Modello UML per il testing La scelta di generare le classi da testare in modo automatico è dovuta alla volontà di verificare la compatibilità dei nostri rilevatori con codice scritto da altri sviluppatori e dalla possibilità di mantenere sincronizzato l implementazione Java con le eventuali modifiche al modello apportate in corso d opera. Una volta ottenuta la base di codice da testare abbiamo proceduto alla scrittura di un buon numero di test utilizzando il framework JUnit. Il codice java che li implementa è riportato nell appendice B. 2