Seminario su 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 dall’evoluzione 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 l’eliminazione delle ridondanze
11. Data re-engineering
Modifico i dati elaborati, allo scopo di riflettere i cambiamenti intervenuti nel software dopo l’esecuzione
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 nell’organizzazione 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 un’analisi 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 all’interno del programma
Problemi nella ristrutturazione automatica:
• Perdita di commenti e di documentazione
• Complessità / pesantezza dell’algoritmo 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 all’anno
 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 dell’input)
 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 l’effettiva 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 dell’architettura (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