Anna Rita Fasolino » 6.Riuso del Software

Outline

• Vantaggi del riuso
• Panoramica sulle forme di riuso
• Design Pattern
• Riuso basato su generatori
• Application Frameworks
• Riuso di COTS

Riuso del Software

Nella maggior parte delle discipline ingegneristiche, i sistemi si progettano a partire da componenti che sono usati anche da altri sistemi.

L’Ingegneria del Software si è originariamente preoccupata soprattutto dello sviluppo di software ex-novo, ma oggi è ben noto che occorre adottare processi di sviluppo basati su un riuso sistematico del software:

• per ottenere software migliore;
• per ottenere software più rapidamente ed economicamente.

Vantaggi del riuso

Riusare software esistente può consentire di:

• Ridurre i costi di sviluppo/testing/manutenzione;
• Produrre software che rifletta il livello di affidabilità dei software riusati: in presenza di software riusabili di grande qualità può essere una ottima opzione.

Riusare è possibile a diversi livelli:

• Riuso di intere applicazioni (es. COTs);
• Riuso di componenti (v. CBSE);
• Riuso di oggetti e funzioni.

Benefici del Riuso

Maggiore affidabilità
Il software riusato è, generalmente, più affidabile (in quanto già provato e testato) di quello prodotto ex-novo.

Minori rischi di progetto
Se si può riusare software, piuttosto che svilupparlo ex-novo, si possono fare stime più accurate sui costi del progetto.

Sviluppo più rapido
I tempi di sviluppo si accorciano ed è possibile consegnare il software più rapidamente.

Problemi legati al riuso

Maggiori costi di manutenzione
Se si riusa software di cui non si possiede il codice, il sistema complessivo potrà risultare meno flessibile e meno manutenibile.

Mancanza di strumenti CASE
Spesso i CASE non forniscono funzionalità che consentono un efficace riuso di librerie di componenti software.

Diffidenza verso software prodotto da altri
Spesso si preferisce risviluppare per avere un maggior controllo sul software prodotto.

Problemi legati al riuso (segue)

Difficoltà nel creare e Mantenere librerie di componenti riusabili;
Popolare librerie di componenti riusabili può essere costoso, e le tecniche disponibili per classificare, catalogare e ricercare componenti software non sono ancora mature.

Difficoltà nel trovare, comprendere ed adattare componenti riusabili;
Non sempre si è disposti a spendere tempo per cercare, comprendere ed eventualmente adattare un componente riusabile.

Fattori di cui tener conto nel pianificare il riuso

• Tempistica richiesta per lo sviluppo;
• Durata prevista per la vita del software;
• Background, capacità ed esperienza del team di sviluppo;
• Criticità del software e altri requisiti non funzionali;
• Dominio di applicazione;
• Piattaforma sulla quale eseguire il sistema.

Diversi Approcci possibili per il Riuso

• Design Patterns;
• Component-based development;
• Application Framework;
• Wrapping di sistemi legacy;
• Sistemi orientati ai servizi;
• Linee di prodotto applicative;
• Integrazione di sistemi COTS (Commercial Off The Shelf);
• Applicazioni verticali configurabili;
• Librerie di programmi;
• Generatori di programmi;
• …

1. Riuso a livello Concettuale

Il Riuso di componenti già implementati obbliga ad ereditare le scelte di progetto e di sviluppo di chi ha realizzato I componenti, limitando le situazione nelle quali il riuso è possibile…

Ad un maggiore livello di astrazione, è possibile invece riutilizzare “concetti”, ovvero scelte effettuate durante la specifica dei requisiti o la fase di progettazione;

• Es. Riuso di schemi di progettazione usati per Algoritmi fondamentali, tipi di dato astratto;
• Design patterns;
• Generative programming.

Design Pattern

• Un Pattern
  • individua un’IDEA, uno schema GENERALE E RIUSABILE
    schema di problema,
    schema di soluzione, etc.
  • Rispetto ai componenti riusabili
    non è un “oggetto” fisico;
    non può essere usato così come è stato definito, ma deve essere contestualizzato all’interno del particolare problema applicativo.
  • Due istanze/contestualizzazioni di uno stesso pattern (ad esempio in problemi diversi) tipicamente sono diverse proprio per la contestualizzazione in domini differenti.

Scopo dei Patterns

Scopo dei pattern

• Catturare l’esperienza e la “saggezza” degli esperti;
• Evitare di reinventare ogni volta le stesse cose.

Cosa fornisce un design pattern al progettista software?

• Una soluzione codificata e consolidata per un problema ricorrente;
• Un’astrazione di granularità e livello di astrazione più elevati di una classe;
• Un supporto alla comunicazione delle caratteristiche del progetto;
• Un modo per progettare software con caratteristiche predefinite;
• Un supporto alla progettazione di sistemi complessi.

Definizione

Definizione:
ogni pattern descrive un problema specifico che ricorre più volte e descrive il nucleo della soluzione a quel problema, in modo da poter utilizzare tale soluzione un milione di volte, senza mai farlo allo stesso modo.

Abbastanza astratti in modo da poter essere condivisi da progettisti con punti di vista diversi.

Non complessi nè domain-specific non rivolti alla specifica applicazione ma riusabili in parti di applicazioni diverse.

Caratteristiche

Un Design Pattern Nomina, Astrae, e Identifica gli aspetti chiave di una struttura comune di design che la rendono utile nel contesto del riuso in ambito object-oriented.

Un Design Pattern identifica

• le classi (e le istanze) partecipanti;
• le associazioni ed i ruoli;
• le modalità di collaborazione tra le classi coinvolte;
• la distribuzione delle responsabilità nella soluzione del particolare problema di design considerato.

Come sono fatti i Design Patterns

Un pattern è formato da quattro elementi essenziali:

1. Il nome del pattern, è utile per descrivere la sua funzionalità in una o due parole.
2. Il problema nel quale il pattern è applicabile.
3. La soluzione che descrive in modo astratto come il pattern risolve il problema. Descrive gli elementi che compongono il design, le loro responsabilità e le collaborazioni.
4. Le conseguenze portate dall’applicazione del pattern. Spesso sono tralasciate ma sono importanti per poter valutare i costi-benefici dell’utilizzo del pattern.

Esempio: Diverse Visualizzazioni dello stato di un oggetto

Il Pattern Observer

• Nome
  • Observer.
• Descrizione
  • Separata la visualizzazione dello stato di un oggetto dall’oggetto stesso.
• Descrizione del problema
  • Usato quando sono richiesti più formati di visualizzazione di stato di un oggetto, e si vuole che l’oggetto non conosca tali formati.
• Descrizione della soluzione
  • Consultare la seguente descrizione in UML.
• Conseguenze
  • C’è accoppiamento minimo fra osservato ed osservatori, pertanto uno svantaggio è sulla impossibilità di ottimizzare le prestazioni dei visualizzatori.

Observer

2. Riuso basato su Generatori

Un generatore è un software che è in grado di generare, a sua volta, software parametrizzato in base a delle specifiche fornite dall’utente.

I generatori possono essere utilizzati nell’ambito di quei problemi per i quali esistono soluzioni ben consolidate che però dipendono notevolmente dai dati in ingresso.

I dati in ingresso al generatore di programmi vanno a descrivere la conoscenza relativa al dominio per il quale debba essere utilizzato il programma da generare.

Riuso basato su Generatori

Esempi di generatori di codice

Generatori di applicazioni per gestione dati aziendali;
I dati di dominio servono semplicemente alla personalizzazione del prodotto.

Parser e analizzatori lessicali per analisi di codice:

• L’input è una grammatica del linguaggio da analizzare; l’output è l’analizzatore del linguaggio;
• Es. Antlr (vedi lezione dedicata);
• Lex&Yacc (per codice C) e JavaCC (per codice Java).

Esempi di generatori di codice (segue)

Generatori di codice basati su modelli

• Ad esempio componenti software, inclusi in strumenti CASE per la modellazione di software, che generano frammenti di codice a partire da modelli (ad esempio da modelli UML).
• DPAToolkit
  • Genera uno scheletro di codice java/cpp che istanzia un design pattern.
• Web Ratio
  • Genera un’applicazione web a partire da un modello codificato in WEBml, che a sua volta estende modelli delle classi e modelli E-R.

Vantaggi e svantaggi dei generatori

Il riuso basato su generatori riduce notevolmente il costo di sviluppo e produce codice molto affidabile.
Tramite generatori di codice si possono ottenere programmi più versatili e performanti di quanto si possa ottenere limitandosi a leggere direttamente dal database, a tempo di esecuzione, i dati relativi alla personalizzazione;
Non tutti i generatori di codice, però, sono in grado di generare codice che sia anche efficiente.
Scrivere una descrizione di dominio per un utente programmatore è più semplice che sviluppare programmi da zero (anche se lo skill richiesto non è minimo).

La loro applicabilità si limita a poche tipologie di problemi.
Spesso il linguaggio col quale descrivere il problema al generatore ha una semantica molto limitata.

Model Driven Architectures (MDA)

Famiglia di standard di modellazione (basata su UML e standardizzata da OMG), pensati allo scopo di generare codice eseguibile a partire da modelli.

• MDA si basa sulla separazione fra livelli di astrazione (dominio, tecnologia, codice);
• MDA si basa sulla automazione della trasformazione fra modelli di diverso livello
  • Ad ogni modello previsto da MDA deve corrispondere una famiglia di strumenti  che attuino le regole di traduzione previste per passare da modelli PIM (Platform Independent Model) verso modelli PSM (Platform Specific Model), e dal PSM verso il codice.

MDA – separazione fra livelli e trasformazioni

La separazione fra modelli PIM, PSM e codice e la traduzione fra modelli attraverso vari pattern.

3. Application Framework

I framework rappresentano modelli astratti di progetto di sotto-sistemi. Le applicazioni si costruiscono integrando e completando una serie di framework.

• Es.: OO Framework
  Composti di una collezione di classi astratte e concrete e di interfacce tra loro;
  Un framework OO è una struttura generica; per realizzare il software bisogna riempire le parti del progetto instanziando le classi astratte necessarie, ed implementando il codice mancante;

Si differenziano dai design patterns per il fatto di essere astrazioni di livello più alto, a livello architetturale anzichè di design.

Classificazioni di framework

Infrastruttura di sistema
Supportano lo sviluppo di infrastrutture come comunicazioni, interfacce utente, e compilatori.

Integrazione di middleware
Composti da standard e classi di oggetti per la comunicazione e lo scambio di informazioni tra oggetti (es. CORBA, COM+, Enterprise Java Beans).

Applicazioni aziendali
Integrano la conoscenza per specifici domini di applicazione (es. telecomunicazioni o sistemi finanziari) e supportano lo sviluppo di nuove applicazioni.

I primi due tipi rientrano anche nella categoria dei Framework Orizzontali mentre le Applicazioni aziendali si considerano come Framework Verticali.

Framework

Spesso i framework sono istanziazioni di una serie di design pattern.

L’utilizzo di un framework da parte di programmatori e progettisti comporta il raggiungimento di un notevole skill riguardante la conoscenza della struttura del framework e delle opportunità da esso messe a disposizione.
Spesso è necessario molto tempo, prima di poter maturare tali conoscenze.

Un esempio: Model-view controller

É un framework usato per la progettazione di GUI.

Permette presentazioni diverse di uno stesso oggetto e fornisce interazioni separate con queste presentazioni.

MVC richiede l’istanziazione di vari design pattern (es. Observer, Strategy, Composite, …).

Model-view-controller

Schema del Framework Model-View-Controller

4. Riutilizzo di intere applicazioni

Consiste nel riutilizzare, eventualmente previa riconfigurazione o personalizzazione, intere applicazioni.

Le applicazioni possono essere riutilizzate direttamente o essere integrate fra loro come componenti indipendenti all’interno di più ampi sistemi.

Esistono due approcci principali:

• Integrazione di COTS;
• Sviluppo di Linee di Prodotti.

Riutilizzo di applicazioni

È sicuramente possibile il riutilizzo di applicazioni che siano senza stato (quindi si limitino a fornire una risposta a seguito di una richiesta).

Ad esempio la filosofia UNIX prevede la costruzione di un gran numero di piccole applicazioni versatili (ad esempio grep) che possano essere composte e ricombinate allo scopo di ottenere applicazioni complesse.

Altro esempio: Web Services.

Riuso di COTS

COTS – Commercial Off-The-Shelf- Software commerciale che può essere usato dai suoi acquirenti senza modifiche (es. Soluzioni desktop, prodotti server…).
Esempio storico di COTS sono i DBMS.

Si tratta di applicazioni complete che spesso offrono un API (Application Programming Interface) per permettere ad altri componenti software di accedere alle proprie funzionalità.

Nella pratica, i COTS sono composti di un insieme di classi astratte di interfaccia visibili all’esterno e di un insieme di classi astratte e concrete non visibili.

Integrazione di COTS

Costruire grandi sistemi integrando COTS è una strategia abbastanza efficiente per sistemi le cui funzionalità base siano abbastanza comuni;
Ad esempio per realizzare sistemi di E-Commerce, potrebbero essere riutilizzabili COTS che implementano soluzioni ai problemi di autenticazione, gestione del database, invio delle e-mail, browsing delle pagine web, etc.

Tramite COTS si velocizza il processo di sviluppo riducendo i costi di sviluppo e test.

Fattori decisionali nella scelta dei COTS

Quali COTS offrono le funzionalità più appropriate?
Possono esserci diversi prodotti COTS utilizzabili tra cui scegliere in base a fattori come costo, completezza, affidabilità.

Come avviene lo scambio dei dati?
L’utilizzo di COTS comporta sempre lo sviluppo di codice per la conversione dei dati verso il formato richiesto dall’applicazione o l’eventuale adattamento dell’applicazione a tali strutture dati.

Quali caratteristiche del prodotto COTS vengono utilizzate?
La maggior parte dei prodotti COTS espongono una grande quantità di funzionalità, molte più di quante necessarie.
È opportuno negare l’accesso alle funzionalità non utilizzate.
Può essere conveniente economicamente scegliere l’adozione di COTS più ridotti.

Esempio: realizzare un sistema di acquisto basato su COTS

Una organizzazione vuole dotarsi di un sistema per consentire ai suoi dipendenti di effettuare ordini dai propri PC.

L’organizzazione possiede già un sistema COTS per l’ordinazione ed uno per la fatturazione e consegna (usato solo dall’ufficio ordini). Si sceglie di costruire il nuovo sistema integrando tali COTS.

Sul lato client, saranno usati programmi standard di e-mail e web browsing.

Sul server, si integrerà una piattaforma per l’e-commerce con I due sistemi esistenti.
Saranno necessari degli adattatori per consentire lo scambio di dati.
Verrà inoltre usato un sistema di e-mail per generare e-mail di notifica e ci sarà bisogno di un altro adattore per ricevere dati dal sistema di fatturazione.

Esempio: Sistema Acquisti basato su COTS

Un esempio di sistema basato su COTS

Integrazione di applicazioni ed Adattatori

Per poter dialogare con applicazioni/componenti esistenti è necessario

• formulare richieste secondo il formato accettato dall’applicazione;
• Interpretare le risposte ottenute nel formato prodotto dall’applicazione.

Possibili soluzioni al problema della realizzazione degli adattatori:

• Per trasformare da/verso formati semplici (ad esempio file di testo) conviene scrivere una classe adaptor;
• Per trasformare tra documenti XML, note le rispettive grammatiche, si può scrivere un documento XSLT dichiarando le regole di trasformazione tra formati. Esistono in commercio componenti anche gratuiti che interpretano i documenti XSLT eseguendo le trasformazioni;
• Per interpretare/costruire documenti XML è possibile utilizzare librerie standard come SAX che forniscono un’API per l’accesso ai contenuti del documento XML;
• Per interpretare formati diversi, non XML, un buon metodo consiste nella scrittura di un parser (eventualmente tramite un generatore automatico come Antlr o JavaCC).

Problemi dei COTS

Mancanza di controllo sulle funzionalità e sulle prestazioni
Il sistema è utilizzato a scatola chiusa: non siamo consapevoli di come avvengano realmente le operazioni nel suo interno e, di conseguenza, non siamo in grado di modulare le richieste in modo da ottimizzare le prestazioni.

Problemi di interoperabilità tra sistemi COTS
Può essere necessario dover scrivere del codice extra per integrare sistemi COTS di produttori indipendenti.

Nessun controllo sull’evoluzione del sistema
Può avvenire che le nuove versioni del sistema rendano impossibile l’interazione col nostro software costringendoci a rimanere legati alle vecchie versioni, per le quali non c’è più manutenzione.

Supporto dei produttori COTS
Tipicamente il supporto dei produttori potrebbe terminare con l’acquisto del prodotto o limitarsi alle sole evoluzioni decise dal produttore.

5. Linee di prodotti software

Per linee di prodotti software si intendono famiglie di applicazioni con funzionalità generiche che si prestano ad essere configurate o adattate in modo da poter essere utilizzate in contesti specifici.

Esempi di adattamento:

• Specifiche configurazioni dei componenti e del sistema;
• Aggiunta di nuovi componenti;
• Selezione di componenti nell’ambito di una libreria;
• Modifiche ai componenti per adattarsi alle esigenze del contesto.

Possibili specializzazioni

Specializzazione della piattaforma
Possono essere necessarie diverse versioni per diversi sistemi operativi o hardware, senza modificare le funzionalità.

Specializzazione dell’ambiente
Possono essere necessarie diverse versioni per venire incontro alle diverse funzionalità e modalità di funzionamento dei dispositivi periferici del sistema.

Specializzazione funzionale
Possono essere necessarie diverse versioni personalizzate in base alle esigenze dei diversi clienti cui sono destinate.

Specializzazione di processo
Possono essere necessarie diverse versioni per supportare I diversi processi di business da eseguire.

Configurazione

Può avvenire in due momenti diversi:

1. Configurazione alla consegna
   • La configurazione avviene per un prodotto finito, senza modificarne internamente la struttura e il progetto, ma solo limitandone/personalizzando le funzionalità (customizzazione).
     • Es. Pacchetti software verticali (es. ERP).
2. Configurazione a tempo di progettazione
   • Tramite l’adozione di patterns e framework generici, le richieste di personalizzazione vengono recepite in fase di progetto e influiscono direttamente sulla realizzazione del prodotto.

Esempio: sistemi ERP

Enterprise Resource Planning (ERP): sistema (generico) che supporta comuni processi aziendali (quali gestione ordini, fatture, inventari, paghe) (es. SAP e BEA).

Il processo di configurazione degli ERP si basa sull’adattamento di un core generico attraverso l’inclusione e la configurazione di moduli, e incorporando conoscenza su processi e regole aziendali del cliente specifico in un database di sistema.

Molto usati in grandi aziende, costituiscono la forma di riuso più comune.

Organizzazione di un Sistema ERP

Architetture per le linee di prodotto

Per mantenere adattabilità e riconfigurabilità è utile adottare architetture modulari e stratificate, che permettano facilmente le necessarie modifiche.
Architettura tipica: multilayer

Inoltre, è importante separare le funzionalità generiche dai dati che si riferiscono alla personalizzazione, in modo da poter realizzare tale customizzazione senza generazione di codice.

Esempio: un generico sistema di gestione risorse

Processo di Sviluppo di una nuova applicazione (da una famiglia di prodotti)

Le fasi del processo di sviluppo

• Raccolta dei requisiti Utente
  • Individuare I requisiti degli utenti attraverso la presentazione del sistema esistente, evidenziando le modifiche necessarie.
• Scelta del Membro della Famiglia più attinente
  • Cercare il membro della famiglia di prodotti che è più vicino al prodotto richiesto.
• Nuova Negoziazione dei Requisiti
  • Eventuale adattamento dei requisiti per minimizzare le modifiche.
• Adattamento Del sistema esistente
  • Sviluppo di nuovi moduli e adattamento dei membri della famiglia.
• Rilascio di un nuovo Membro della Famiglia
  • Consegnare e documentare chiaramente il nuovo membro della famiglia (per sviluppi futuri).