Tesi di Laurea
Upcoming SlideShare
Loading in...5
×
 

Tesi di Laurea

on

  • 604 views

Framework per il debug da remoto

Framework per il debug da remoto

Statistics

Views

Total Views
604
Views on SlideShare
604
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Tesi di Laurea Tesi di Laurea Presentation Transcript

    • UN FRAMEWORK BASATO SU PLUG-IN PER IL DEBUGGING DA REMOTO UNIVERSITA’ DEGLI STUDI DEL SANNIO IN BENEVENTO Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica Relatore: prof. ZIMEO Eugenio Candidato: PESCATORE Felice mat.: 195 / 000.485 Anno Accademico 2003 / 2004
    • IL DEBUGGING
      • Scopo dello studio è fornire un applicativo con le funzionalità fondamentali per il debugging da remoto.
      • Il debugging costituisce l’analisi approfondita di un programma al fine di trovare gli errori (bug) che ne provocano un comportamento errato.
      • L’uso del debugging permette di ottenere software più affidabili, aumentando notevolmente la qualità del prodotto.
      • E’ fondamentale evidenziare che indipendentemente dal tipo di analisi che si conduce su un programma, non si potrà mai avere la garanzia dell’assenza di errori, ma solo la prova della loro presenza (tesi di Dijkstra)
      Il Debugging
    • IL DEBUGGING DA REMOTO
      • Il debugging da remoto è una variante del debugging classico. Infatti la differenza è dovuta alla modalità di analisi dell’applicazione, cosa che non avviene localmente (cioè sulla stessa macchina) ma attraverso una rete.
      • Il software lavora sfruttando il classico paradigma Client / Server: il client riceve ed elabora i dati inviati dal server;
      classica struttura client-server Il Debugging  Debugging da Remoto
    • IL PROGETTO Il Progetto  Caratteristiche Generali L’analisi dei requisiti richiesti dal progetto, ha portato ad individuare le caratteristiche fondamentali del debugger Queste caratteristiche sono alla base di uno dei modelli software di maggior successo degli ultimi anni: i FRAMEWORK . SEMPLICITA’ FLESSIBILITA’ PORTABILITA ’ PROGETTO
    • PORTABILITÀ SU PIÙ PIATTAFORME
      • Per raggiungere il requisito di portabilità., si è scelto di realizzare il debugger sfruttando tecnologie di largo uso:
      • TCP (UDP) / IP , come Protocolli di Rete ;
      • JAVA , considerato il linguaggio multipiattaforma per eccellenza;
      • XML : il più diffuso linguaggio di mark-up ;
      • LINUX : quale sistema operativo Unix Like ;
      • WINDOWS con tecnologia NT : quale O.S. Windows;
      Il Progetto  Portabilità
    • SEMPLICITA’ DI UTILIZZO
      • La semplicità di utilizzo è un requisito dettato da una ragione molto semplice: l’utilizzatore deve potersi concentrare sul lavoro che sta svolgendo, senza perdere troppo tempo a cercare di capire il funzionamento del debugger.
      • Per raggiungere tale scopo si è:
      • realizzata una funzionale interfaccia grafica ;
      • utilizzato linguaggio semplice e chiaro per la descrizione delle varie funzionalità;
      • corredato il software da una guida all’uso .
      Il Progetto  Semplicità di Utilizzo
    • LA FLESSIBILITA’
      • Dopo aver condotto uno studio preliminare si è giunti alla conclusione che la possibilità di integrare funzionalità attraverso moduli esterni, detti plug-in, era la soluzione migliore per rendere il debugger altamente flessibile.
      Il Progetto  La Flessibilità Realizzabile da terzi Nuove funzionalità Modifica delle funzionalità esistenti Esempio: per passare da un server TCP a uno UDP basta cambiare il Plug-in!
    • VANTAGGI E SVANTAGGI DEI PLUG-IN
      • L’uso dei plug-in comporta, ovviamente, sia vantaggi che svantaggi.
      • Tra i principali vantaggi dei plug-in possiamo annoverare:
          • flessibilità (punto chiave del nostro progetto);
          • il programma di base è più leggero ;
          • chiunque può di sviluppare moduli per integrare funzionalità aggiuntive;
      • Gli svantaggi principali sono:
          • aumento della complessità di progettazione del programma di base;
          • problemi di sicurezza poiché chiunque può essere in grado di progettare un plug-in;
          • stabilità del software dipendente direttamente dalla qualità dei plug-in.
      Il Progetto  Flessibilità  Vantaggi e Svantaggi dei Plug-in
    • I FRAMEWORK
      • Un framework è un sistema software semi-completo , riusabile , e relativo ad uno specifico dominio di un problema . Esso rappresenta, in pratica, lo scheletro dell’applicativo finale.
      • Caratterizzandolo:
      • Non è una libreria
      • Rende disponibili le funzionalità di base
      • Reagisce in modo efficiente ai cambiamenti
      • Deve essere adattato
      Il Progetto  I Framework
    • DOCUMENTAZIONE DI UN FRAMEWORK
      • Essendo i framework indirizzati agli sviluppatori, bisogna realizzare una documentazione precisa e facilmente comprensibile che comprenda:
      • presentazione dello specifico dominio del problema;
      • specifiche di progetto;
      • descrizione dei componenti realizzati;
      • risultati dei test effettuati;
      • note ed indicazioni varie;
      • elenco dei limiti e dei problemi conosciuti
      • Utile risulta anche l’inserimento delle motivazioni che hanno portato alla realizzazione del framework stesso e un analisi sui possibili sviluppi futuri.
      Il Progetto  I Framework  Documentazione
    • IL FRAMEWORK FReDe
      • Il framework FReDe racchiude le caratteristiche peculiari fin qui presentate e rappresenta lo scheletro per lo sviluppo di future applicazioni di debugging da remoto.
      • Il framework si presta alle seguenti situazioni d’uso:
      Elaborazione dei dati provenienti dal server Salvataggio dei risultati e successive rielaborazioni Visualizzazione dei risultati delle elaborazioni Settaggio dei parametri di analisi dei dati FReDe
    • FReDe PLUG-IN
      • La gestione dei plug-in di FReDe è affidata al componente denominato plug-in header , che garantisce:
      • indipendenza e isolamento tra i vari moduli;
      • Efficienza nel caricamento, nel funzionamento e nel controllo dei plug-in.
      FReDe  Plug-in
    • CONFIGURAZIONE DI FReDe
      • L’intero framework è configurabile attraverso l’uso di file XML, ampiamente usato in questo progetto.
      FReDe  Configurazione INITINFO.XML HEADER.XML SETTING.XML Il software include al suo interno diverse classi di gestione dell’XML e una di essere realizza un mini editor per modifica dei file esistenti.
    • CASE STUDY: JTELSEY (Java Telsey)
      • JTelsey è una specializzazione
      • del framework FReDe, realizzato per la Telsey S.p.A.
      • Scopo del programma è quello di
      • permettere il debugging da
      • remoto del TDE (TEST DEVICE
      • EQUIPMENT), ovvero del
      • componente progettato dalla
      • stessa azienda.
      • JTelsey incorpora tutte le caratteristiche di FReDe ed in più sono stati realizzati i seguenti plug-in:
        • Blowfish , per la decodifica dei dati di debugging
        • LevelTads , per il filtraggio
        • Tads , per l’incapsulamento in un oggetto dei dati di debugging
        • RegEx , per ulteriori operazioni di filtraggio
      FReDe Case Study
    • STRUTTURA DI JTELSEY
      • Le classi componenti JTelsey possono essere organizzate e trattate in base alle funzionalità che realizzano.
      FReDe Case Study  Struttura In particolare alle classi di Gestione dei Plug-in è demandato il compito più delicato dell’intero progetto
    • TESTING DI JTELSEY
      • Paradossalmente anche un software di debugging (ovvero di testing) ha bisogno di essere testato.
      FReDe Case Study  Testing Questi, insieme a quello di regressione , sono alla base dei processi di testing definiti dalla moderna ingegneria del software.
    • VERIFICA FUNZIONALE DI JTELSEY
      • La verifica funzionale è stata condotta direttamente presso la Telsey S.p.A.
      • Grazie alla collaborazione degli ingegneri dell’ azienda, in particolare dell’ing. Izzo, sono stati testati e analizzati tutti gli aspetti dell’applicazione. In particolare:
        • Stabilità
        • Funzionalità
        • Correttezza dei risultati
        • Interfaccia Utente
      • La verifica ha portato ad un prodotto maturo ed affidabile, ma soprattutto rispondente alle specifiche richieste.
      FReDe Case Study  Verifica Funzionale
    • CONCLUSIONI
      • Dall’analisi fatta risulta come la progettazione e l’implementazione di un framework sia un’attività molto articolata.
      • In particolare, bisogna:
      • comprendere fino in fondo le motivazioni e la necessità di realizzare il framework;
      • fare un’analisi minuziosa dei requisiti tenendo conto dei possibili sviluppi futuri;
      • effettuare una implementazione chiara e comprensibile;
      • realizzare una documentazione accurata;
      • essere sicuri che il prodotto rilasciato sia funzionale e risponda ai requisiti prefissati.
    • SVILUPPI FUTURI
      • Il progetto FReDe prevede ampi margini di sviluppo futuro:
      • Creazione di un server ad-hoc che permetta di scaricare i plug-in da una rete;
      • Creazione di un sistema di certificazione dei plug-in;
      • Estensione dei sottosistemi di stampa e di organizzazione dei dati elaborati.
      • sarebbe interessante poter rilasciare il prodotto sotto licenza GPL o CREATIVE COMMONS, in modo da consentirne uno sviluppo aperto e recepirne consigli e miglioramenti tecnici.