Software Re Engineering
- 1. Software Re-engineering (Cap. 28 Sommerville) Universit degli Studi di Siena - Facolt di Ingegneria Informatica Anno Accademico 2004 / 2005 Corso di Ingegneria del Software Realizzato da: Docente: Fabrizio Panti Prof. Tommaso Bolognesi Fabrizio Panti Software re-engineering 1
- 2. Software re-engineering E come software engineering, per嘆 riferito a sistemi gi esistenti Migliora la mantenibilit di un sistema software, senza cambiarne le funzionalit E un concetto differente dallevoluzione di un software Principale applicazione: Legacy systems ed in generale in tutti i sistemi in cui sarebbe pi湛 costoso farne la manutenzione Altre applicazioni: eventi eccezionali ed imprevisti (es. Millennium Bug, Buffer overflow, ) Perch辿 non riscrivere daccapo il software? Forward System Design and New engineering specification implementation system Software Existing Understanding and Re-engineered re-engineering software system transformation system Riprogettare da zero lo stesso sistema software sarebbe pi湛 costoso e rischioso! Fabrizio Panti Software re-engineering 2
- 3. In pratica Passi del processo di software re-engineering: 2. Source code translation Traduco il codice del software in un linguaggio di programmazione diverso o in una versione moderna dello stesso linguaggio 4. Reverse engineering Analizzo il codice sorgente del software (senza modificarlo) per recuperare la struttura e la specifica Mi serve per capire le funzionalit del sistema 7. Program structure improvement Riorganizzo la struttura, allo scopo di migliorarla rendendola pi湛 semplice da leggere e da capire Program modularisation Unisco parti di programma correlate. Ho quindi leliminazione delle ridondanze 11. Data re-engineering Modifico i dati elaborati, allo scopo di riflettere i cambiamenti intervenuti nel software dopo lesecuzione dei passi di re-engineering soprastanti Tolgo le inconsistenze tra i dati Posso rendere distribuito il sistema, mettendo dei dati in un database centrale Costi del processo di software re-engineering: - Ampiezza del software da modificare - Qualit del software - Tools disponibili per il re-engineering - Disponibilit di personale esperto Fabrizio Panti Software re-engineering 3
- 4. Source code translation E la forma pi湛 semplice e meno costosa di software re-engineering Traduzione del codice sorgente in un altro linguaggio di programmazione (es. da Fortran a C) o in una versione pi湛 moderna dello stesso linguaggio (es. da COBOL-74 a COBOL-85) In questa fase non 竪 necessario comprendere le funzionalit del programma Pu嘆 essere necessario fare la traduzione del codice per le seguenti ragioni: Aggiornamento della piattaforma hardware (vecchi compilatori potrebbero non funzionare) Scarsezza nelle abilit del personale dedito alla manutenzione Cambiamenti nellorganizzazione politica (un particolare linguaggio potrebbe venire standardizzato) Mancanza di supporto software System to be System to be Re-engineered re-engineered re-engineered system Identify source Design translator Automatically Manually code differences instructions translate code translate code Una traduzione completamente automatica 竪 impossibile costrutti in un certo linguaggio potrebbero non avere una diretta equivalenza in un altro linguaggio Fabrizio Panti Software re-engineering 4
- 5. Reverse engineering Analisi del codice sorgente per recuperare la struttura e la specifica del sistema E un processo che non modifica il programma in esame, si attua solamente per capirne le funzionalit Ha come input il codice sorgente Program structure diagrams Automated analysis System to be System Document Data structure re-engineered information Manual generation diagrams store annotation Traceability matrices Questo processo inizia con una fase di analisi e si conclude con la produzione di numerosi documenti E un processo per lo pi湛 automatico ed iterativo Fabrizio Panti Software re-engineering 5
- 6. Program structure improvement La struttura del programma tende a degradare con la manutenzione ordinaria (vengono generalmente aggiunte nuove istruzioni e condizioni) Il codice tende quindi a crescere e a diventare pi湛 ingarbugliato E pi湛 difficile e rischioso effettuare nuove modifiche Nel lungo termine esse potrebbero rendere del codice incomprensibile, potrebbero creare falle nel sistema o, peggio ancora, potrebbero rendere non raggiungibili alcune parti di codice e non ce ne accorgeremo finch辿 non ne viene fatta unanalisi intensa Alcuni errori da evitare: Scrivere programmi con etichette GOTO anzich辿 con i costrutti condizionali IF-THEN- ELSE o con cicli WHILE (es. sul Sommerville del controllore della temperatura) Utilizzare strutture di controllo ingarbugliate Ad esempio evitare di scrivere: IF (A < B AND C > D AND NOT (E <= F)) THEN istruzioni END IF E preferibile semplificare le condizioni! Fabrizio Panti Software re-engineering 6
- 7. Program structure improvement Ristrutturazione automatica di un programma Program to be Analyser and Program Restructured restructured graph builder generator program Graph conversione in un grafo diretto viene generato un programma strutturato (senza GOTO) representation Il grafo mostra come il controllo si muove allinterno del programma Problemi nella ristrutturazione automatica: Perdita di commenti e di documentazione Complessit / pesantezza dellalgoritmo di ristrutturazione Inevitabile necessit di fare interventi integrativi manuali (specialmente se il programma da modificare 竪 scritto in un linguaggio non standard) Il secondo punto (la complessit) si pu嘆 snellire applicando la ristrutturazione solo a sottoprogrammi: - scompongo il programma in parti - scelgo quelle di peggior qualit e quelle soggette a cambiamenti pi湛 frequenti Alcune metriche per decidere quando ristrutturare: failure rate percentuale di codice modificato allanno complessit delle componenti Fabrizio Panti Software re-engineering 7
- 8. Program modularisation Unisco parti di programma correlate Posso cos狸 scovare e rimuovere le ridondanze Questa fase non pu嘆 essere automatizzata (o solamente in piccolissima parte) E necessario identificare manualmente le relazioni tra componenti Tipi di moduli che possono essere creati in questa fase: Hardware modules Raggruppano funzioni usate per controllare un particolare dispositivo hardware Functional modules Uniscono funzioni che effettuano calcoli simili su task correlati (es. validazione dellinput) Process support modules Raggruppano degli oggetti (dati, funzioni, ) che si riferiscono ad uno specifico processo produttivo o di affari (es. gestione prestiti bibliotecari) Data abstractions Collezionano insieme dati e processi associati (pi湛 in dettaglio, --------------->) Fabrizio Panti Software re-engineering 8
- 9. Program modularisation Recovering data abstractions Vengono creati dei tipi di dato astratti che ne nascondono leffettiva rappresentazione, pur dando la possibilit di accedere ai dati e modificarli Per effettuare la conversione tra dati e ADT 竪 necessario: Analizzare le aree di dati comuni per identificare delle astrazioni logiche Creare un ADT per ognuna di queste astrazioni Usare un programma che generi dei riferimenti incrociati, per trovare tutti i riferimenti ai dati e sostituirli con le chiamate alle rispettive funzioni Questo processo di conversione 竪 costoso dal punto di vista temporale, ma ha il pregio di essere estremamente mirato Fabrizio Panti Software re-engineering 9
- 10. Data re-engineering E necessario per riallineare i dati con i cambiamenti attuati nei precedenti passi Riorganizzo le strutture dati e talvolta anche i valori Ho quindi due lavori che devo eseguire: migliorare la comprensione dei dati togliere le inconsistenze tra i valori Posso automatizzare buona parte di questi processi Principali necessit di fare il data re-engineering: degradazione dei dati (errori e duplicati) limiti originariamente fissati nel programma (es. anni rappresentati con 2 cifre) evoluzione dellarchitettura (es. se un sistema centralizzato lo rendo distribuito) Risolvo questi problemi con i seguenti approcci: data cleanup data extension data migration Fabrizio Panti Software re-engineering 10
- 11. Data re-engineering Nei legacy systems formati da numerosi programmi cooperanti possono verificarsi i seguenti problemi: problemi di denominazione dei dati (nomi non intuibili o differenti) problemi di lunghezza dei campi problemi di organizzazione dei record (linguaggi di programmazione diversi possono organizzare i record in modi differenti) letterali mal codificati assenza del dizionario dei dati (non so i nomi dei dati usati, la loro rappresentazione e il loro uso) Finora abbiamo affrontato il problema della modifica delle strutture dati; potrebbe essere necessario anche modificare alcuni valori Posso infatti avere delle inconsistenze nei valori: inconsistent default values inconsistent units (es. pounds/kilograms) inconsistent validation rules (dati scritti da un programma potrebbero venir respinti da un altro) inconsistent representation semantics (un programma potrebbe dare un significato diverso allo stesso oggetto se 竪 rappresentato in un altro modo) inconsistent handling of negative values Fabrizio Panti Software re-engineering 11