Manutenzione e Reverse Engineeringunina.stidue.net/Ingegneria del Software 2/Materiale... · 2010....

1

Ingegneria del Software 2 – Manutenzione e Reverse Engineering 1

Manutenzione e Reverse Engineering


Riferimenti

• Sommerville , Ingegneria del Software, 8a ed., Capitolo 21

Ulteriori Letture Raccomandate• Grady Booch, Nine Things you can do with old software, IEEE

Software, Sept/Oct 2008• Canfora, Di Penta “Frontiers of Reverse Engineering:

a Conceptual Model”, FOSM08 – IEEE Comp. Soc. 2008

2


La Manutenzione del software- generalità

• Qualsiasi software, dopo il rilascio della prima release, avràbisogno di essere modificato.

• I sistemi software sono, per loro natura, sistemi evolutivi checambiano durante la loro vita.

• Ciò deriva dal fatto che, durante la vita del sistema, le caratteristiche che lo definiscono cambiano, cambiando sia le esigenze di chi usa il software, sia dell’ambiente del mondoreale in cui il sistema opera.– Più I requisiti del sistemasono instabili, o specificano un problema

in maniera incompleta ed approssimativa, più il sistema avràbisogno di cambiare.

• L’evoluzione di un software è dunque inevitabile!


Motivazioni per il cambiamento

• Errori possono essere individuati e devono esserecorretti;

• Il dominio del software può evolvere;• Nuovi requisiti possono emergere dopo il rilascio;• Nuove tecnologie hardware e software possono

affermarsi nel frattempo;• Può essere necessario migliorare la qualità del software

(ad esempio l’affidabilità o le performance).

3


L’importanza dell’evoluzione

• Le organizzazioni proprietarie hanno fatto grossiinvestimenti per I loro sistemi software, che sonorisorse critiche!

• Per preservare i l valore di tali risorse, I sistemidevono necessariamente cambiare ed evolvere.

• La manutenzione è un’attività costosa e la maggiorparte del budget speso per il software è in generespeso per la sua manutenzione, piuttosto che per ilsuo sviluppo.


I costi della manutenzione

• Un tipico progetto di sviluppo software mediamente dura tra 1 e 2 anni, mentre…

• La durata del periodo di manutenzione può variare tra 5 e 6 anni [1]– Più della metà dei costi di un progetto software sono spesi

per la manutenzione– Recenti survey riportano la regola dell’ 80-20, ossia 80% di

sforzo speso per la manutenzione e 20% per lo sviluppo.

• [1] Parikh and Zvegintzov, Tutorial on Software Maintenance, IEEE, 1993

4


L’ingegneria del software come processo evolutivo

Specification Implemention

ValidationOperation

Star t

Release 1

Release 2

Release 3

- La vita di un sistema evolve attraverso varie Release- Ogni Release nasce dalla necessità di cambiare o far evolvere la Release precedente


Evoluzione o Declino?

• Fino a che punto si può continuare a far evolvere un sistema software?

• Quando si deve decidere di gettare il vecchio sistema e sostituirlo con uno nuovo?

• Alcune domande da porsi:– Il costo di manutenzione è troppo alto?– L’affidabilità del sistema è inaccettabile?– Non si riesce più ad adattare il software in tempi accettabili?– Le prestazioni sono inaccettabili?– Le funzionalità del sistema sono poco utili?– Ci sono altri sistemi che fanno lo stesso lavoro meglio, più

velocemente ed economicamente?– Il costo di manutenzione dell’hardware è diventato tale da

giustificare la sostituzione con nuovo hardware?

5


Leggi dell’Evoluzione del Software

• Ci sono delle regole valide in generale per i sistemi software, che ci permettono di capire cosa sta accadendo ad un sistema in evoluzione?

• Una valida indicazione può giungerci dallo studio delle serie storiche di alcuni dati (es. dimensioni, complessità, risorse richieste, facilità di manutenzione)

• Se l’evoluzione di tali dati seguisse un andamento ‘invariante’, dalla loro osservazione potremo dedurre cosa sta accadendo al software


Leggi dell’evoluzione del software

• Proposte da Lehman e Belady [1] a partire dal 1976, in seguito a studi empirici basati inizialmente sull’osservazione dell’evoluzione di 4 versioni successive di un S.O. IBM– Modifiche continue– Complessità crescente– Evoluzione dei grandi sistemi leggi iniziali– Stabilità organizzativa– Conservazione della familiarità– Crescita continua– Qualità deteriorata leggi più recenti– Sistema feedback

6


Le Leggi di Lehman

• Modifiche continue– Un sistema deve necessariamente cambiare, o diventerà

progressivamente inutile.

• Complessità crescente– Quando un sistema viene modificato, la sua struttura si

deteriora: per evitare ciò bisogna investire sulla manutenzione preventiva.

• Evoluzione dei grandi sistemi– I grandi sistemi hanno una loro dinamica che è caratterizzata

da comportamenti e trends regolari che possono essere usati per fare predizioni : in particolare, la dimensione, il tempo fra due release successive, il numero di errori rilevati sono approssimativamente invarianti per ogni release.


Le Leggi di Lehman

• Stabilità organizzativa– Raggiunto lo stato ‘saturo’, non ci possono essere variazioni

significative nella produttività dello staff • Conservazione della familiarità

– Le modifiche incrementali per ogni release sono approssimativamente costanti

• Crescita continua– Le funzionalità offerte dai sistemi devono crescere

continuamente, per la soddisfazione degli utenti• Qualità deteriorata

– La qualità dei sistemi si deteriora se non si interviene con adattamenti ai nuovi ambienti operativi

• Sistema feedback– I processi evolutivi incorporano sistemi feedback utili al

miglioramento dei prodotti

7


Applicabilità delle Leggi di Lehman

• Le leggi di Lehman sembrano applicabili a sistemi digrandi dimensioni e personalizzati, sviluppati davaste organizzazioni.

• Non è chiaro come dovrebbero essere modificateper:– Sistemi ottenuti attraverso wrapping;– Sistemi che incorporano molti componenti COTS;– Piccole organizzazioni;– Sistemi di medie dimensioni.


Tipi di Manutenzione del software

• Classificazione degli interventi di manutenzione– Manutenzione correttiva

• Modifiche per correggere difetti

– Manutenzione adattativa• Modifiche per adattare il software a cambiamenti dell’ambiente

operativo (hardware, software di base, interfacce, organizzazione, legislazione, ecc.)

– Manutenzione perfettiva• Estensione dei requisiti funzionali, o migliorie di requisiti non funzionali

in risposta a richieste dell’utente

– Manutenzione preventiva• Modifiche che rendono più semplici le correzioni, gli adattamenti e le

migliorie– Manutenzione di emergenza

• Manutenzione correttiva non programmata, necessaria a mantenere ilsistema in funzione

8


Distribuzione dello sforzo di manutenzione [1]

Preventiva4%

Perfettiva50%

Adattativa25%

Correttiva21%

[1] Lientz, Swanson, Problems in application software maintenance, 1981Communication of the ACM


Problemi della manutenzione

• In gran parte dipendono dalla mancanza di controllo e disciplina nelle fasi di analisi e progetto del Ciclo di Vita del Software

• Alcuni fattori tecnici:– difficoltà nel comprendere un programma scritto da altri– mancanza di documentazione completa/ consistente

– software non progettato per modifiche future– difficoltà nel tradurre una richiesta di modifica di

funzionamento del sistema in una modifica del software– valutazione dell’impatto di ciascuna modifica sull’intero

sistema– la necessità di ritestare il sistema dopo le modifiche– la gestione della configurazione del software

9


• Stabilità del team– I costi di manutenzione si riducono se lo stessostaff s i occupa

della manutenzione per lungo tempo• Responsabilità contrattuale

– Sviluppo e manutenzione sono talvolta appaltati ad aziendediverse, cosicchè chi sviluppa non ha interesse a semplificare illavoro di chi effettuerà la manutenzione

• Capacità dello staff– Chi s i occupa della manutenzione potrebbe non avere lo stesso

livello di esperienza e pratica di chi lo ha sviluppato• Età e struttura del programma

– Gli interventi di manutenzione tendono a far deteriorare la qualità del software e quindi a rendere più difficili tutti gliinterventi di manutenzione necessari• v. anche G. Visaggio, “Aging of a legacy system: symptoms and

remedies”, Journal of Software Maintenance, Wiley

Fattori di Costo della manutenzione


Prevedere la Manutenzione

• Per una più efficace ed efficiente gestione di un sistema in evoluzione, è utile riuscire a:– prevedere i probabili cambiamenti del sistema, e le

parti più esposte ai cambiamenti – prevedere le parti più difficili da mantenere– Prevedere i costi di manutenzione per un dato periodo.

• Quali fattori possono essere considerati per fare tali previsioni?

10


Prevedere i cambiamenti del sistema

• Per prevedere i probabili cambiamenti del sistema occorre analizzare le sue dipendenze dall’ambiente esterno:– Più dipendenze ci sono, più è probabile che le modifiche

dell’ambiente innescheranno modifiche nel software– Elementi da valutare:

• Numero e complessità delle interfacce del sistema

• Numero dei requisiti volatili (basati su requisiti di dominio instabili)

• Processi aziendali in cui il sistema è usato (maggiore è tale numero, più probabili sono le possibili richieste di cambiamento).


Prevedere la Manutenibilità

• La manutenibilità può essere definita come la probabilità che, in determinate condizioni d’uso, unaattività di manutenzione possa essere condotta entroun prefissato intervallo di tempo, usando definite procedure e risorse.

• La manutenibilità può essere valutata da due diverse prospettive (interna ed esterna)– Prospettiva interna: analizzando attributi interni del software,

come quelli relativi alla sua struttura– Prospettiva esterna: si basa su attributi del processo di

manutenzione

11


Valutare la manutenibilità in base ad attributi interni del software

• Molti studi hanno indagato la relazione fra attributi interni del software e manutenibilità.– Si è riscontrato che lo sforzo di manutenzione si

concentrava sempre sui componenti più complessi.– Metriche di complessità usabili per predire:

• Complessità ciclomatica di McCabe• Volume di Halstead,• Numero di Linee di Codice (LOC)• Fan-in, Fan-out

– Altre Metriche per valutare la leggibilità del codice …


Valutare la manutenibilità secondo la prospettiva esterna

• Si usano dati sul processo di manutenzione per predire la manutenibilità– Il numero di richieste di manutenzione correttiva

• un loro aumento nel tempo può indicare riduzione della manutenibilità

– Tempo medio richiesto per l’analisi dell’impatto– Tempo medio per implementare una richiesta di modifica– Numero di richieste di modifica in attesa

• Altri dati utili:– Numero di problemi non risolti, tempo speso su problemi non

risolti, % di modifiche che hanno introdotto nuovi difetti, numero di componenti modificati per implementare una modifica…

12


Prevedere i costi di manutenzione

• Si basa sulla previsione delle richieste di modifica e della manutenibilità del sistema.

• Molti metodi di stima dei costi si basano sullo sforzo necessario per comprendere il software e per sviluppare nuovo codice (es. COCOMO2).

• Es. Equazione di Lehman e Belady:M= p+ K c-d

M= sforzo di manutenzione, p= sforzo di sviluppo totale, c è la complessità causata dalla mancanza di strutturazione e documentazione, d è il grado di familiarità del team di manutenzione col software


Il processo di evoluzione del software

Regression/SystemTesting

Regression/SystemTesting

AcceptanceTesting

AcceptanceTesting

Identificazione del Problema/ Richiesta

di modifica

Identificazione del Problema/ Richiesta

di modifica

Analisi dell’impattoAnalisi

dell’impattoPianificazione della Release

Pianificazione della Release

ImplementazioneImplementazioneNuova Release

13


Implementazione della modifica

Requirementsupdating

Softwaredevelopment

Requirementsanalysis

Proposedchanges


Manutenzione “d’urgenza”

• In alcuni casi le richieste di manutenzione devonoessere soddisfatte rapidamente:– Se un difetto serio deve essere riparato;– Se modifiche dell’ambiente operativo causano effetti

collaterali imprevisti sull’operatività del sistema;– Se è necessario l’adeguamento urgente a seguito di

cambiamenti imprevisti (es. Ambiente o mercato)

• In questo caso, le fasi di analisi e progetto dellamodifica potrebbero non essere eseguite , implementando direttamente il cambiamento.

14


Processo di riparazione d’urgenza (quick- fix model)

Vecchio sistema

requisitiprogettocodicetest

Nuovo sistema

requisitiprogettocodicetest

- Con tale approccio, la qualità complessiva del software si ridurrà.- Utile pianificare interventi di aggiornamento della documentazionee/o di miglioramento della qualità del software.


Gli interventi per ‘Ringiovanire’ il software

• Sono finalizzati a migliorare la manutenibilità di un software ormai deteriorato dagli interventi di manutenzione subiti.

• Diverse tipi di intervento possibili:

• Ridocumentazione• Restructuring (o Refactoring)• Reengineering• Reverse Engineering

15


Ridocumentazione

• Consiste in una analisi statica del codice sorgente (attraverso appositi strumenti) al fine di produrre documentazione del sistema. Si analizzano:– usi delle variabili, chiamate fra componenti, path del flusso di

controllo, dimensioni dei componenti, parametri di chiamate, .. Per capire cosa fa il codice e come lo fa.

• Gli output di una attività di ridocumentazione possono essere:– grafi delle chiamate,tabelle delle interfacce delle funzioni,

dizionari dati, diagrammi del data-flow o control-flow, pseudo-codice, cross-reference fra componenti o variabili

– Tali output si possono usare per verificare se il software ha bisogno di ristrutturazione.


AllslsllslAllalaAllala----------

Restructuring

• Attività che trasforma il codice esistente in codiceequivalente dal punto di vista funzionale, ma miglioratodal punto di vista della sua qualità.

• In genere si esegue in tre passi:1. Analisi statica del codice per ottenerne una

rappresentazione interna (es. call graph, control-flowgraph…)

2. Semplificazione della rappresentazione interna attraverso tecniche di trasformazione automatiche.

3. La nuova rappresentazione viene usata per generare una versione strutturata (migliorata) ed equivalente al codice originario.

AllslsllslAllalaAllala----------

16


Refactoring

• Anche i sistemi object-oriented sono soggetti al deteriorarmento e diventano legacy!

• Il refactoring è un insieme di tecniche usabili per migliorare il codice ed il design di sistemi object-oriented.

• Martin Fowler è autore del libro “Refactoring: Improving the Design of Existing Code” (1999)dove presenta più di 70 pattern per eseguire il refactoring.

• Tali tecniche cercano di eliminare i cosiddetti Bad Smells dal codice.


Refactoring

• “Refactoring is the art of improving the design of existing code.Refactoring provides us with ways to recognize problematic code and gives us recipes for improving it.” [William C. Wake]

• “A change to the system that leaves its behavior unchanged, but enhances some non-functional quality - simplicity, flexibility, understandability, ...” [Kent Beck]

• “The process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal structure” [Fowler]

17


Esempi di Bad Smells nel codice

……

Extract ClassCambiamenti divergenti in una classe (una classe è soggetta a cambiamenti per tanti motivi)

Replace parameter withMethod

Lunghe liste di parametri di metodi

Extract Class, Extract Sub-Class, Extract Interface

Classi troppo grandi

Extract MethodMetodi troppo lunghi

Extract MethodCodice duplicato

Pattern di Refactoringapplicabile

Problema (Bad Smell)


Esempi di Tool per il Refactoring

Net Beans Refactoring Eclipse Refactoring

18


Risorse per il refactoring

• Alcune risorse riguardanti il refactoring :– Esempi pratici di refactoring

• http://ocw.kfupm.edu.sa/user062%5CSWE31601/18_Refactoring.ppt

– Per divertirsi: un torneo sulla realizzazione di strumentidi refactoring

• http://www.metodiagili.it/torneo.html

– Un’azienda che si occupa di reverse engineering dicodice sorgente, refactoring, etc.

• http://www.semdesigns.com/Products/DMS/DMSToolkit.html?Home=Refactoring


Reengineering

• It is the examination and alteration of a subject system to reconstitute it in a new form and the subsequent implementation of the new form [Chikofsky and Cross ]

• La reingegnerizzazione (reengineering) è un’attività di re-implementazione di un sistema software svolta per migliorarela manutenibilità di un software esistente.

• Essa può comprendere:– Ridocumentazione, Ristrutturazione e riscrittura di parte

del software (o anche di tutto) senza modificarel’insieme di funzionalità che esso realizza

19


Obiettivi del Reengineering

• Modularizzazione del sistema– Suddivisione di un sistema monolitico in parti da riusare

separatamente• Miglioramento delle Performance

– Migliorare le prestazioni di un sistema esistente• Migrazione (o Porting) verso altre Piattaforme

– Necessità di localizzare I componenti dipendenti dallapiattaforma

• Estrazione del progetto– Per migliorare maintainability, portability, etc.

• Usare una nuova Tecnologia– quali nuove caratteristiche di un linguaggio, standards,

librerie, etc.


Tecniche per il Reengineering

• Restructuring– automatic conversion from unstructured to structured code– source code translation

— Chikofsky and Cross • Data reengineering

– integrating and centralizing multiple databases– unifying multiple, inconsistent representations– upgrading data models

— Sommerville, ch 21• Refactoring

– renaming/moving methods/classes etc.

• Reverse Engineering– analisi del codice ed estrazione di informazioni relative alla sua

struttura e funzionalità

20


Il ciclo di vita del Reengineering

Requirements

Designs

Codice

(0) analisi dei requisiti

(1) Cattura delmodello

(2) Individuazionedel problema (3) Soluzione

del problema

(4) Trasformazione del programma

• Processo che richiedeintervento umano


Reengineering vs. Restructuring

• Reengineering– attività di ristrutturazione a livello della riorganizzazione

dell’architettura modulare di un sistema; si parte da unacerta organizzazione dei moduli del sistema e del relativoflusso dati, e se ne producono altre con miglioricaratteristiche di qualità, come ad esempio, la riduzionedell’accoppiamento fra i moduli, il controllo dell’uso divariabili globali e la riorganizzazione di data repository e cosìvia

• Restructuring (o Code Refactoring)– attività che trasforma il codice esistente in codice

equivalente dal punto di vista funzionale, ma migliorato dalpunto di vista della sua qualità

21


Forward engineering e reengineering

Understanding andtransformation

Existingsoftw are system

Re-engineeredsystem

Design andimplementation

Systemspecification

Newsystem

Softw are re-engineering

Forward engineering


Reverse Engineering

• È un’attività che consente di ottenere specifiche e informazionisul design di un sistema a partire dal suo codice, attraverso processi di estrazione ed astrazione di informazioni.

• La definizione di Chikofsky and Cross, 1990 [1]:• Analyzing a subject system

– to identify the system's components and their inter-relationships and

– to create representations of the system in another form or at a higher level of abstraction

• A two-steps process– information extraction– view abstraction

[1] Chikofsky and Cross, Reverse engineering and design recovery: A taxonomy . IEEE Software,1990

22


What is reverse engineering

WorkProduct Parsers+

Analyzers

Fact base

Viewcomposers

WorkProduct


Fasi di Estrazione ed Astrazione

• Estrazione– Analisi del codice o di altri artifatti software, allo scopo di

ottenere informazioni relative al sistema analizzato.– Particolarmente utili sono quelli strumenti in grado di estrarre

informazioni da un codice sorgente qualsiasi, nota che sia la grammatica del linguaggio di programmazione (ad esempioJavaCC)

• Astrazione– Si esaminano le informazioni estratte e si cercano di astrarre

diagrammi, o viste, ad un più alto livello di astrazione (es.: diagrammi di progetto, architetturali, del dominio dei dati)

– I processi di astrazione non sono completamenteautomatizzabili poichè necessitano di conoscenza ed esperienza umana

23


Un Modello concettuale per il ReverseEngineering

• Canfora e Di Penta [1] hanno recentemente proposto un modello concettuale che sistematizza tutti i concetti chiave di un processo di reverseengineering, quali:

• Goal del processo• Artifatti coinvolti nel RE• Analizzatori usabili• Viste producibili

• [1] Canfora, Di Penta “Frontiers of Reverse Engineering:a Conceptual Model”, FOSM08 – IEEE Comp. Soc. 2008


A conceptual model

• Built around the outlined process – Core model: reverse engineering process, reverse

engineering goals, basic concepts– Artifacts: the various objects involved in reverse

engineering tasks– Analyzers: tools/activities that analyze software

artifacts to populate a knowledge base– Views: higher level representations built by querying

the knowledge base

24


A conceptual model - Core Model

Recommendation

Software Engineer

Renewed ProductLegacy Product

Change Task

Change goal

Reverse Engineering goal

Understanding goal

Software Product

Software viewAbstractor

Information base

AnalyzerSoftware Artifact

cd: Core

analyzes+

populates+ queries+ 1

<role>+

1

creates+

satisfies+

satisfies+

produces+

activates+

informs+

expresses+

explores+

triggers+

uses+

feedback

related to+

Reverse Engineering Process [Chikofsky and Cross]

is developed by+


Reverse Engineering Goals

• Reverse engineering tasks are performed to satisfy reverse engineering goals:

– Change goals: produce a renewed product• e.g. through migration, modernization, modularization

– Understanding goals: increase the current understanding of a software product

• Produce high level views by means of an Abstractor• Can start from source code, but also from binary• Examples of targets: recovering architectures, design,

traceability links, building metric views

25


Interaction with the Reverse Engineer

• Reverse engineering is often (semi) automatic • However interaction with software engineers is crucial

– Of course, they explore views produced by reverse engineering

– They can send a feedback that helps to produce a better view

• E.g. Rocchio feedbacks can be used to improve IR-based traceability recovery (although their performances are questionable)


Continuous reverse engineering

• Full integration in the development process

class foo{void m1(){…}void m2(){…} void m3(){…}

}

InteractiveReverse engineering

InteractiveReverse engineering

LOC=234Cycl=12.5

LOC=234Cycl=12.5

Feedback to

the heuristic

EvolutionaryDevelopment

class foo{void m1A(){…}void m2(){…}

}class bar

extends foo{void m1B(){…}void m3(){…}

}

26



Recommendation

Software Engineer


Change Task

Change goal


Understanding goal

Software Product


Information base


cd: Core

analyzes+


<role>+

1

creates+

satisfies+

satisfies+

produces+

activates+

informs+

expresses+

explores+

triggers+

uses+

feedback

related to+


is developed by+


Analyzers

Hybrid Analyzer

Binary File

Binary Analyzer Evolution History

Source Code Execution Trace

Code Analyzer

Historical AnalyzerDynamic AnalyzerStatic Analyzer

Analyzer

cd: Analyzers

analyzes+

analyzes+

analyzes+

analyzes+

27


Static analysis• Source code or other artifacts are

parsed and then a model is built– Island grammars or code

transformations as alternatives• Relatively fast and cheap ?• Complete ?• Difficult to capture

behavioral/dynamic models– State machines– Sequence diagrams– Detect behavioral patterns

• Intrinsic difficulties increasing with highly dynamic systems ?– Pointer analysis– Polymorphism– Ultra-late binding

…if(x==0){

System.out.println(j);

}while(y>0){

…}

…

Parser

seq

seq

seqwhile

if… … … … …

Analyzer

Source code

Parsetree

ModelAcademicRecordcourse_code : Stringyear : Datesemester : Integergrade : String

Coursecourse_code : Stringcourse_name : Stringcredit_points : Integer

AcademicInCharge

Studentstudent_id : Stringstudent_name : Stringcurrent_fees : Money

0..*0..*CourseOffering

year : Datesemester : Integerenrolment_quota : Integer

0..*0..*

0..*

0..1

0..*

0..1

*

* takes

*

*

takes_crsoff

has_stud


Dynamic analysis• System exercised by means of

– test cases– realistic usage scenario

• Collecting execution traces– Code instrumentation– Patching virtual machines

• Able to deal with dynamicity ?• Useful to extract dynamic models ?

• Code must be compilable ?• The quality of the models built

depends on the data used for execution ?

• Might be incomplete ?• Might be expensive ?

obj1 : Class1 obj2 : Class2msg1

msg2

obj1 : Class1 obj2 : Class2msg1

msg2

Return x1, x2, …

Execution

…while(y>0){

if(x==0){o.f();br.write(“f”);

}o.g();…

br.write(“g”);}

…

Instrumentedsource code

Real usage scenario

Testcases

f g g f g g f g g g

OnFirstFloor

Idleentry/timer = 0

do/increase timer

Movingdo/moving to floor

go up (floor)

arrivedgo down (floor)

[timer = time-out]/go down (first floor)

go up (floor)

OnFirstFloor

Idleentry/timer = 0

do/increase timer

Idleentry/timer = 0

do/increase timer



go up (floor)

arrivedgo down (floor)

[timer = time-out]/go down (first floor)

go up (floor)

Analyzer

Executiontrace

Dynamic models

28


Historical analysis

• Static and dynamic analysis do not capture information such as:– How does an artifact change during the time?– When was it changed?– Why was it changed?

• New requirements, bug-fixing, refactoring, re-documentation…

– Who changed it?– What artifacts changed together?


Multidimensional analysis• Combining static, dynamic and historical

analysis

Static

Dynamic

Time

29



Recommendation

Software Engineer


Change Task

Change goal


Understanding goal

Software Product


Information base


cd: Core

analyzes+


<role>+

1

creates+

satisfies+

satisfies+

produces+

activates+

informs+

expresses+

explores+

triggers+

uses+

feedback

related to+


is developed by+


Artifacts

Data

Software Engineer

Configuration FileBuild FIleRequirementUser Docs

Evolution History

Test case

Dependence

Execution Trace

User

Executable

Property

Traceability Link

Similarity Artifact Relationship

Binary

Patch

Revision

Change Request

Source CodeDesign ModelAnalysis Model

Software Artifact

cd: Software Artifacts

evo lves as+

produces+

resolves+

compi led in+

is descr ibed by

executes+produces+

exercises+

invo lves+

describes the evolut ion of+

issues+

is descr ibed by

assigned to+

submits+

Static Analysis Dynamic Analysis

Historical Analysis

Decompilation

impacts+

30


Artifacts• Different kinds of artifacts are used for

– Static analysis: requirements, design models, source code, data, configuration/build files, any textual documentation, etc.

• Decompilation as a particular case: binaries– Dynamic analysis: execution traces– Historical analysis: for each artifact a sequence of revisions are

available through CVS/SVN

• Not always all artifacts necessary for an understanding/change task are available ? reverse engineering extracts them


What about the knowledge base ?

? Many schemata and fact bases to exchange reverse engineering information have been defined so far

? Examples:

– CIA repository– Refine– Rigi Standard Format (RSF)– FAMIX– Tuple-Attribute (TA) language– Graph Exchange Language (GXL)– OMG - Knowledge-Discovery

Metamodel (KDM)

KDM

31



Recommendation

Software Engineer


Change Task

Change goal


Understanding goal

Software Product


Information base


cd: Core

analyzes+


<role>+

1

creates+

satisfies+

satisfies+

produces+

activates+

informs+

expresses+

explores+

triggers+

uses+

feedback

related to+


is developed by+


View

Understanding goal

Querying mechanism

Filter

Information base

Abstractor

Revision Historical View

Integrated View

Code ViewArchitectural View Metric View

Artifact Relationship

Software Artifact

Property

Software Engineer

Software view

cd: Software View

explores+

is described by

involves+

represents+

represents+

represents+

evolves as+

creates+

defines granularity level+

uses+

uses+

queries+

satisfies+

expresses+

32


Software Views• Built by query the information base using a querying mechanism• Examples:

– Grok: notation for manipulating binary relations using the Tarski’srelational algebra [Holt, 1998]

– Use of Turing complete languages , such as the one of the software Refinery toolkit

– Use of logic programming (e.g. Prolog) [Canfora et al., 1992]– GuPRO: declarative language for querying graph structures– CrocoPat: relational calculus to query RSF information bases– XQuery: When facts are stored in a XML information base (e.g. those

produced by SrcML)• Represented as

– Artifacts and artifact relationships


Different kinds of views

Architectural View

? Example: RIGI[Wong et al. 1995]

Polimetric View

? Example: CodeCrawler[Lanza and Ducasse, 2003]

33


Different kinds of views

Code View

? Example: CodeSurfer[Anderson and Teitelbaum, 2001]

Historical View? Example: Evolution Storyboards

[Beyer and Hassan, 2006]


Running Example I? Metrics-based clone detection

[Mayrand et al., 1996]? Clones: software artifacts exhibiting the same (similar) set of

metrics? Detecting cloned methods? Metrics are extracted from the source code (artifact) by means of

a static analyzer? Knowledge base populated with metric sets for each artifact

(method in our case)? The clone detector queries the knowledge base queried to detect

clones? Clones visualized with a HTML clone viewer

34


Object Diagram

Clone View Builder: Abstractor

Clone Viewer: Code ViewClone Detector:Querying Mechanism

Metric Profile:Information Base

Metric Extractor:Code Analyzer

Linux Kernel:Source Code

cld: Clone Detection


Il problema dei Legacy Systems

• Un sistema legacy (“ereditato”) – é spesso vecchio (10 anni o più di vita);– è di grandi dimensioni (centinaia di migliaia di linee di codice) – è scritto in assembler o in un linguaggio di vecchia generazione– è stato probabilmente sviluppato prima che si diffondessero i

moderni principi dell’ingegneria del software– La manutenzione é stata svolta in modo da seguire le modifiche

nei requisiti, aumentando così l’entropia (il disordine) del sistema

– La manutenzione risulta ormai difficile e costosa– Realizza funzionalità cruciali e irrinunciabili per l’organizzazione– Contiene anni di esperienza accumulata nell’ambito del dominio

specifico del problema

35


La gestione dei Sistemi Legacy: due decenni di strategie

‘80 2000‘90

Coyle, IEEE Software 2000

Migrazione verso architetture

client - server a due livelli

Integrazione in piattaforme OO

attraversowrappers

Migrazioneverso

architetture a tre livelli

Integrazione nel mondo del

WWW


Un sistema legacy obbliga il management a cercare soluzioni e strategie di manutenzione

• Svariate alternative disponibili:– Eliminazione del sistema e sviluppo di un nuovo sistema– Recupero dei componenti più preziosi del sistema,

sostituendo i restanti con prodotti preconfezionati (COTS)– Eliminazione dei componenti ormai inutili, del codice

obsoleto e dei dati “morti” – Congelamento del sistema as is, e riutilizzo mediante

tecniche di wrapping– Manutenzione Ordinaria– Manutenzione Preventiva (re-documentation, restructuring o

reengineering) – Migrazione …

36


Una recente analisi di strategie proposta da Grady Booch

G. Booch, Nine things you can do with old software, IEEE Software, Sept 2008

• Abbandonarlo – quando il suo valore economico si è esaurito, o lo sforzo

di risviluppo non è eccessivo• Regalarlo

– Se non serve più, si può cederlo a qualche comunità open-source dove potrà ancora tornare utile a qualcuno

• Ignorarlo– Se è abbastanza stabile, e fa qualcosa di utile, si può

continuare a usarlo senza però modificarlo.


Nove cose da poter fare con software legacy

• Farlo sopravvivere– Quando l’hardware su cui gira non è più supportato (e non si

dispone del codice sorgente per portarlo in nuove piattaforme), si fa sopravvivere o cercando vecchio hardware da cannibalizzare, o usando emulatori di piattaforma.

• Riscriverlo– Quando la manutenzione è troppo costosa, o il sistema è

troppo fragile, si può riscriverlo (ma sapendo che ottenere un sistema funzionalmente equivalente al primo è impossibile, e che bisognerà probabilmente convincere gli utenti ad accettare qualche cambiamento)

• Farlo fruttare (in qualche modo)– Cercare parti del sistema da conservare (algoritmi, pattern,

astrazioni…) perché ancora utili, ed usarle come una base di conoscenza per un nuovo sviluppo

37


Nove cose da poter fare con software legacy

• Wrapping

– Usare tecniche di wrapping per integrarlo in nuove piattaforme (quali SOA)

• Trasformarlo– È la strategia più difficile e va praticata per mantenere il

sistema in condizioni ottimali, se si prevede di continuare ad usarlo a lungo termine: va dal semplice refactoring, alla trasformazione architetturale.

• Preservarlo– Anche il software antico può avere un valore storico (es.

vecchi sistemi operativi, o videogiochi) e culturale da preservare (magari in un Museo della Storia dei Computer)


Conclusione di Booch

• Per Software economicamente interessante ci sono due possibili opzioni di gestione:

• Preservarlo – Si fa per motivi soprattutto irrazionali (avversione al

rischio)• Farlo evolvere

– Quando ciò può contribuire al suo valore a lungo termine

• La scelta è alla fine sempre dettata da fattori economici (e non tecnici)!

38


System quality and business value

12

3 45

67

89

1 0

System quality

High business valueLow quality High business value

High quality

Low business valueLow quality

Low business valueHigh quality


Legacy system categories

1. Low quality, low business value– Dovrebbe essere abbandonato

2. Low-quality, high-business value– Realizza funzionali importante ma è costosomantenerlo.

Dovrebbe essere reingegnerizzato in modo da rendere le future (necessarie) operazioni di manutenzione più agevoli ed efficaci(cioè finire nel quarto caso)

3. High-quality, low-business value– Si può decidere sia di abbandonarlo (in quanto poco

importante), sia di rimpiazzarlo con COTS (se realizza qualcosadi generale, indipendente dal dominio specifico) oppuremantenerlo (dato che i costi di manutenzione saranno limitati)

4. High-quality, high business value– Su di essosi eseguono le operazioni di manutenzione

• In questo modo, però, la qualità diventerà via via più bassa, fino a finire nel secondo caso

Manutenzione e Reverse Engineeringunina.stidue.net/Ingegneria del Software 2/Materiale... · 2010....

Documents

Transcript of Manutenzione e Reverse Engineeringunina.stidue.net/Ingegneria del Software 2/Materiale... · 2010....