Modeling, analyzing, and monitoring interacting software components

Developers build software systems combining and integrating functionalities provided by different components. This practice is good and desirable from the software reuse perspective, but it requires developers a deep and detailed understanding of the behavior of the components they use. Unfortunately, these aspects are seldom formally specified. Most of the time the only documentation available is a high level natural language description instead of a detailed formal specification. Moreover these descriptions often consider each component in isolation and they possibly leave out a whole class of interesting behaviors related to the interaction of different pieces of software that arise only when developers combine them. In this work, we address these issues with models, which we can infer through dynamic analysis, apt to describe the behavior of a single component as well as the interactions among different pieces of software. We developed two different kinds of models: Behavioral Equivalence Models (BEMs) and Protocol Behavior Models (PBMs). Behavioral Equivalence Models encode all the details of the behavior of a component, or of a set of interacting components, within a small but significant scope. We infer these models through the exhaustive exploration of a small scope. We build the scope by combining all the possible operations interleaving up to a certain trace length using a relevant set of parameter values. If the parameters are chosen properly and if we consider traces long enough we can get a precise description of the behavior of a component. On the opposite, Protocol Behavior Models provide a generalized and abstract representation of software behaviors. These models are designed to show components’ behavior from a higher level perspective that is not bound to the specific parameter values used at inference time. We propose a technique to synthesize Protocol Behavior Models from the information encoded in Behavioral Equivalence Models. Looking at these models, developers can get a precise idea of the behavior of software components. In particular, the models highlight corner cases, exceptional behaviors and the protocols of interaction that developers have to follow to get the desired results without incurring in errors or misbehaviors. Models are useful by themselves to better understand how software components work, but they can also be used as the basis for other more sophisticated and automated applications. In fact, we can leverage the knowledge they embed to statically check programs source code for components misuse that possibly lead to errors. We can also highlight pieces of code that, although working, are not robust and pinpoint the implicit assumptions that make it work. This information is useful for program comprehension and it makes program maintenance tasks easier. Another application of the models we propose is runtime monitoring of components that developers cannot control. Nowadays it is common to rely on functionalities provided by external services. These services are often developed, maintained and deployed by third parties. As a consequence there is no guarantee that their behavior will not change over time. In this work we propose an approach that combines the information encoded in the two models to monitor the behaviors of external components. It checks that an external component behavior still complies with the one encoded in the models known to developers when they designed and implemented the system. We faced the challenges of inferring the, usually missing, initial specification for a given component as well as of detecting violations at runtime and of keep- ing the models updated with the most updated observations. The latest point is particularly interesting because it allows us to deal with possible model in- completeness by keeping gathering information while the system is running and using the component.

Nell’ambito dell’ingegneria del software, è comune costruire sistemi complessi combinando ed integrando le funzionalità fornite da diversi componenti. Questa è una buona pratica dal punto di vista del riutilizzo di software esistente, ma ha anche lo svantaggio di richiedere agli sviluppatori una certa familiarità con i componenti utilizzati. È infatti richiesta una profonda e dettagliata comprensione del comportamento dei componenti. Purtroppo, questi dettagli sono specificati in modo formale solamente in pochissimi casi. La maggior parte dei componenti software utilizzati nella costruzione di sistemi complessi presenta solamente una documentazione di alto livello, spesso in linguaggio naturale, che solo raramente copre tutti gli scenari possibili. Inoltre, queste descrizioni spesso considerano ogni componente come una entità a sé stante. Viene quindi trascurate una intera classe di comportamenti molto interessanti che si manifesta solamente quando diversi componenti vengono combinati e fatti interagire tra loro. In questo lavoro, abbiamo affrontato questi problemi introducendo dei modelli appositamente studiati per descrivere sia il comportamento di un singolo componente, sia i comportamenti che scaturiscono dall’interazione tra diversi componenti software. Abbiamo sviluppato due diversi modelli, Behavioral Equivalence Model (modelli di equivalenza comportamentale) and Protocol Behavior Model (modelli del protocollo di comportamento). Entrambi i modelli sono delle macchine a stati finiti con una precisa caratterizzazione degli stati e le cui transizioni rappresentano l’esecuzione di operazioni sui com- ponenti che descrivono. Assieme ai modelli, abbiamo sviluppato anche delle tecniche di inferenza per poterli estrarre automaticamente. Queste tecniche sono basate sull’analisi dinamica del codice eseguibile dei componenti per cui vogliamo estrarre i modelli. Un Behavioral Equivalence Model codifica tutti i dettagli del comportamento di un componente, o di un insieme di componenti, all’interno di una piccola ma rilevante porzione dello spazio degli stati in cui il componente può trovarsi. Questa scelta si basa sull’assunzione che, solitamente, possiamo coprire tutti i comportamenti che un componente può avere considerando solamente un numero limitato di casi: idealmente ogni caso rappresenta un esempio di un particolare comportamento del componente. Inferiamo questi modelli attraverso l’esplorazione esaustiva di uno spazio limitato. Costruiamo questo spazio combinano tutte le possibili sequenze di operazioni (entro una certa lunghezza) che possiamo effettuare sul componente. Se una operazione richiede dei parametri, nelle tracce di esecuzione consideriamo diverse sue invocazioni ottenute utilizzando dei valori provenienti da un piccolo ma significativo insieme definito a priori. Scegliendo in modo appropriato i valori da utilizzare come parametri e considerando delle tracce di esecuzione sufficientemente lunghe possiamo ottenere una descrizione precisa di tutti i dettagli del comportamento di un componente. Al contrario, un Protocol Behavior Model mostra una rappresentazione generalizzata ed astratta del comportamento del componente. Questi modelli sono stati pensati per rappresentare i comportamenti ad un livello di astrazione maggiore. In particolare, non mostrano i dettagli legati a degli specifici valori dei parametri o prodotti dall’esecuzione delle operazioni. Al contrario, i parametri vengono ignorati mentre i valori restituiti vengono astratti con la terminazione normale o eccezionale dell’operazione. La tecnica di inferenza che proponiamo per ottenere i Protocol Behavior Model si basa sull’astrazione delle informazioni contenute nei Behavioral Equivalence Model. Lo studio delle informazioni contenute in questi modelli può dare agli sviluppatori una idea molto precisa sul comportamento di un componente software. Degli aspetti molto importanti di questi modelli sono il loro evidenziare casi particolari, comportamenti eccezionali e il protocollo di interazione che deve essere seguito dagli sviluppatori per poter ottenere i risultati desiderati senza incorrere in errori o malfunzionamenti. I modelli, che sono utili per sé come descrizione formale del comportamento di un componente, possono anche essere utilizzati come base da cui partire per sviluppare applicazioni più sofisticate ed automatizzate. Nel corso del lavoro che ha portato a questa tesi abbiamo sviluppato due diverse applicazioni delle informazioni contenute nei modelli: uno strumento di analisi statica del codice e uno strumento di monitoraggio del comportamento di componenti gestiti da una terza parte. La tecnica di analisi statica che abbiamo introdotto sfrutta le informazioni contenute nei modelli per cercare dei problemi nell’utilizzo di componenti che interagiscono tra loro. Lo strumento che abbiamo realizzato riesce ad individuare errori all’interno del codice sorgente per cui l’esecuzione di determinate istruzioni non può che avere un comportamento eccezionale. Inoltre, il nostro approccio all’analisi statica può anche evidenziare istruzioni che, sebbene funzionanti correttamente, sono fragili, ovvero che funzionano solamente perché qualche assunzione è implicitamente soddisfatta. Questa informazione può essere molto utile perché permette di correggere il codice rendendolo più robusto e, di conseguenza, permette di rendere più semplici e sicure eventuali modifiche al programma durante la fase di manutenzione del suo ciclo di vita. Una seconda applicazione dei modelli proposti in questa tesi è il monitoraggio del comportamento durante l’esecuzione di componenti fuori dal controllo degli sviluppatori di un sistema. È sempre più comune fare affidamento sulle funzionalità fornite da servizi esterni che, solitamente, sono sviluppati, gestiti ed operati da una terza parte. Di conseguenza, un problema molto importante è il controllare che non ci siano cambiamenti nel comportamento dei componenti esterni utilizzati dal sistema. In questo lavoro proponiamo un approccio che combina le informazioni codificate nelle due tipologie di modelli che abbiamo sviluppato per monitorare il comportamento di un componente esterno. Durante l’esecuzione del sistema, lo strumento che abbiamo realizzato controlla che il comportamento del servizio sotto osservazione sia sempre compatibile con quello descritto dai modelli che gli sviluppatori hanno usato come riferimento mentre hanno integrato il componente esterno nel sistema. In questo contesto abbiamo affrontato sia il problema di inferire la specifica iniziale del servizio esterno sia quelli di identificare delle violazioni e di mantenere i modelli aggiornati con tutte le informazioni disponibili raccolte durante l’esecuzione del sistema. Questo ultimo aspetto è particolarmente interessante in quanto ci permette di gestire l’incompletezza dei modelli ottenuti inizialmente andando a raccogliere nuove informazioni mentre il sistema è in esecuzione e utilizza il componente esterno.