Lezione 7: Riuso del Software Outline

Lezione 7: Riuso del Software
Riferimenti:
I.Sommerville, Ingegneria del Software, 8°
edizione- Cap. 18 (Riuso)
Ingegneria del Software 2 – Riuso del Software
1
Outline
•
•
•
•
•
•
Vantaggi del riuso
Panoramica sulle forme di riuso
Design Pattern
Riuso basato su generatori
Application Frameworks
Riuso di COTS
Ingegneria del Software 2 – Riuso del Software
2
1
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 exnovo, ma oggi è ben noto che occorre adottare
processi di sviluppo basati su un riuso sistematico del
software:
– per ottenere software migliore e
– per ottenere software più rapidamente ed
economicamente.
Ingegneria del Software 2 – Riuso del Software
3
Vantaggi del riuso
•
Riusare software esistente può consentire di:
–
–
•
Ridurre i costi di sviluppo/ testing
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 e dimensioni:
–
–
–
Riuso di intere applicazioni (es. COTs)
Riuso di componenti (v. CBSE)
Riuso di oggetti e funzioni
Ingegneria del Software 2 – Riuso del Software
4
2
Quali cose possono essere riusate?
• Non bisogna pensare solo al codice!
• È possibile riusare anche:
–
–
–
–
–
L’Architettura di un sistema
I progetti
L’analisi
La documentazione (sia tecnica che utente)
I test
Ingegneria del Software 2 – Riuso del Software
5
Benefici del Riuso
• Maggiore affidabilità
– Il software riusato è, generalmente, più affidabile (in
quanto già provato e testato) di quello prodotto exnovo.
• 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
Ingegneria del Software 2 – Riuso del Software
6
3
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
Ingegneria del Software 2 – Riuso del Software
7
Problemi legati al riuso
• 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.
Ingegneria del Software 2 – Riuso del Software
8
4
Panoramica di approcci per il Riuso
Design
patterns
Component
frameworks
Component-based
development
Application
product lines
Aspect-oriented
software development
COTS
integ ration
Legacy system
wrapping
Prog ram
generators
Configurable ver tical
applications
Service-oriented
systems
Prog ram
libraries
Ingegneria del Software 2 – Riuso del Software
9
Approcci per il Riuso (1)
Design patterns
Generic abstractions that occur across appli cations are
represented as design patterns that show abstract and concrete
objects and interactions.
Component-based
development
Systems are developed by integrating components
(collectio ns of objects) that conform to component-model standard
.
Application
frameworks
Collections of abstract and concreteclasses that can be
adapted and extended to create application systems.
Legacy system
wrapping
Legacy systems (see Chapter 2) that can be wrapped b y
defining a set of interfaces and providing access to these
legacy systems through these interfaces.
Service-oriented
systems
Systems are developed by linking shared services that may be
externally provided.
Ingegneria del Software 2 – Riuso del Software
10
5
Approcci per il Riuso (2)
Applicat ion product
lines
An application type is general ised around a co mmo n
architecture so that i t can be adapted in different wa ys for
different cus tom ers.
COTS integrat ion
Syst ems are dev eloped by int egrating exist ing application
syst ems.
Configurable verti cal
applica tions
A generic s ystem is desi gned so that it ca n be c onfigured to
the nee ds of sp ec ific sy stem custom ers.
Program l ibra ries
Class and function libraries imp lementing com m onl y-used
abstract ions are a vailable for reuse.
Program gener ators
A generator s ystem emb eds knowledge of a particul ar types
of applicat ion and can generate sys tems or syst em fragm ents
in that dom ain.
Aspec t-oriented
soft ware devel opment
Share d com ponents are woven int o an application at different
place s when the program is compiled.
Ingegneria del Software 2 – Riuso del Software
11
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
…
Ingegneria del Software 2 – Riuso del Software
12
6
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 nelle tecnologie di riuso
Criticità del software e altri requisiti non funzionali
Dominio di applicazione
Piattaforma sulla quale eseguire il sistema
Ingegneria del Software 2 – Riuso del Software
13
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 (es. algoritmi, interfacce,
linguaggi,…), limitando le situazione nelle quali il riuso è
possibile…
•
Ad un maggiore livello di astrazione, è possibile invece
riutilizzare “concetti”, progetti astratti, privi di dettagli
implementativi
–
–
–
Es. Riuso di schemi di progettazione usati per Algoritmi
fondamentali, tipi di dato astratto;
Design patterns
Generative programming
Ingegneria del Software 2 – Riuso del Software
14
7
Riuso di schemi di progettazione
• Alcuni esempi:
• Algoritmi Fondamentali
– Ricerca, Ordinamento, Visita di Alberi, etc…
• Tipi di Dato Astratto
– Pila, coda, albero, lista, tabella
Ingegneria del Software 2 – Riuso del Software
15
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
Ingegneria del Software 2 – Riuso del Software
16
8
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
Ingegneria del Software 2 – Riuso del Software
17
Definizione
• Ogni pattern descrive:
– un problema specifico che ricorre più volte
– e 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
Ingegneria del Software 2 – Riuso del Software
18
9
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
Ingegneria del Software 2 – Riuso del Software
19
Elementi fondamentali dei Design Patterns
(secondo Gamma et al.)
Un pattern è descritto 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 descrizione della soluzione. È un modello che 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.
Ingegneria del Software 2 – Riuso del Software
20
10
Esempio.
Il problema: ottenere diverse visualizzazioni
dello stato di un oggetto
30
25
15
30
20
1
2
15
3
Serie1
4
25
5
10
10
20
5
0
1
2
3
4
5
Soggetto
Dato1: 15
Osservatore 1
Dato2: 25
Osservatore 2
Dato3: 20
Dato4: 10
Dato5: 30
Il problema di ottenere diverse visualizzazioni di uno stesso soggetto
Ingegneria del Software 2 – Riuso del Software
21
Descrizione del Pattern Observer
•
•
Nome: Observer.
Descrizione:
– Separa la visualizzazione dello stato di un oggetto dall’oggetto stesso.
Quando lo stato dell’oggetto cambia, le sue visualizzazioni sono
avvertite del cambiamento e sono aggiornate automaticamente
•
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
•
Conseguenze
– Consultare la seguente descrizione in UML.
– C’è accoppiamento minimo fra osservato ed osservatori, pertanto uno
svantaggio è sulla impossibilità di ottimizzare le prestazioni dei
visualizzatori .
Ingegneria del Software 2 – Riuso del Software
22
11
Observer
La classe Subject conosce I suoi osservatori
e fornisce una interfaccia per attaccare e
staccare oggettiObserver e una per
notificare a tutti gli Observer i cambiamenti
del Subject.
La classe Observer definisce
una interfaccia per oggetti a cui
dovrà essere notificata una
modifica del Subject.
observerState= subject->GetState();
return subjectState ;
Lo schema UML del Pattern Observer
Ingegneria del Software 2 – Riuso del Software
23
Observer: comportamento dinamico
:
ConcreteObserver
:
ConcreteSubject
External
Source
attach(Observer)
setState( )
update( )
notify( )
getState( )
Ingegneria del Software 2 – Riuso del Software
24
12
Categorie di Pattern
•
Un esempio di catalogo DP è presente nel libro Erich Gamma,
Richard Helm , Ralph Johnson, John Vlissides , “Design Patterns:
Elements of Reusable Object Oriented Software“.
– I pattern qui descritti sono spesso denominati pattern GoF (Gang of
Four), per ricordarne i 4 autori
•
Esistono diverse categorie di pattern, che descrivono la
funzione (purpose) e il dominio (scope) del pattern.
•
Funzione (purpose), ovvero cosa fa il pattern:
– Creazionali (creational): forniscono meccanismi per la
creazione di oggetti
– Strutturali (structural): gestiscono la separazione tra interfaccia
e implementazione e le modalità di composizione tra oggetti
– Comportamentali (behavioral): consentono la modifica del
comportamento degli oggetti minimizzando le necessità di
cambiare il codice
Ingegneria del Software 2 – Riuso del Software
25
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
Ingegneria del Software 2 – Riuso del Software
26
13
Generative programming
• È un paradigma di ingegneria del software basato sulla
modellazione di famiglie di sistemi che, data una particolare
specifica dei requisiti, ottiene automaticamente un sistema
customizzato ed ottimizzato
•
•
– A partire da componenti elementari riusabili
– Adottando processi automatici di trasformazione e configurazione
– La specifica del sistema viene eseguita mediante Domain
Specific Languages (DSL)
Consente di ridurre il time-to-market, e migliorare la qualità del
software prodotto e la produttività
Gli strumenti di Generative programming usano le tecnologie dei
parser e dei compilatori
– http://www.programtransformation.org/ Transform/GenerativeProgrammingWiki
Ingegneria del Software 2 – Riuso del Software
27
Riuso basato su Generatori
Conoscenza
Conoscenzadel
del
Dominio
Dominioapplicativo
applicativo
Descrizione
Descrizione
dell’applicazione
dell’applicazione
Generatore
Di programma
Programma
generato
Database
Database
La generazione di un programma attraverso un generatore di codice
Ingegneria del Software 2 – Riuso del Software
28
14
Esempi di generatori di codice (1)
•
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
Lex&Yacc (per codice C) e JavaCC (per codice Java)
Ingegneria del Software 2 – Riuso del Software
29
Esempi di generatori di codice (2)
• 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
– http://dpatoolkit.sourceforge.net/
– 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
– http://www.webratio.com/Home.do?link=oln489d.redirect
Ingegneria del Software 2 – Riuso del Software
30
15
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
Ingegneria del Software 2 – Riuso del Software
31
Model Driven Architectures (MDA)
• Famiglia di standard di modellazione (basata su UML e
standardizzata da OMG [1]), 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
• L’approccio MDA ha l’obiettivo di fornire uno standard
completo per la creazione di modelli indipendenti
dall'implementazione, in modo che possano essere "mappati" su
qualsiasi piattaforma, presente o futura
[1] Specifiche di MDA: http://www.omg.org/docs/omg/03-06-01.pdf
[2] Elenco di MDA tools: http://www.modelbased.net/mda_tools.html
Ingegneria del Software 2 – Riuso del Software
32
16
Modelli nell’MDA
• modello PIM (Platform Independent Model)
– definisce le funzionalità di business ed il
comportamento del sistema, indipendentemente dalla
sua implementazione tecnologica
• modelli PSM (Platform Specific Model)
– consente di "mappare" il PIM su una specifica
tecnologia (Java, CORBA, web ...), senza alterare il
PIM stesso.
• Il linguaggio UML è usato per specificare PIM e PSM
Ingegneria del Software 2 – Riuso del Software
33
MDA- processo di sviluppo
•La definizione di PIM e PSM si avvale di Patterns predefiniti,
personalizzabili e riusabili, così come la trasformazione da PIM a
PSM (patterns tecnologici) e la generazione del software (patterns
di implementazione) a partire dal PSM.
Pattern di
Trasformazione
Pattern Funzionali
PIM
patterns
Patterns
tecnologici
PSM
patterns
Patterns
implementativi
Codice
Ingegneria del Software 2 – Riuso del Software
patterns
34
17
Famiglie di strumenti necessari per l’MDA
•
•
•
•
•
•
Tool di modellazione
Tool di analisi del modello
– Per la verifica di presenza di inconsistenze, incompletezze,
errori nei modelli
Tool di test
– Per eseguire verifiche model-based dei modelli
Tool di traduzione che attuino le regole di traduzione previste
per passare
– da modelli PIM verso modelli PSM
– dal PSM verso il codice.
…
Molte implementazioni degli standard di modellazione OMG
sono presenti nell’ Eclipse Modeling Framework (EMF) e
Graphical Modeling Framework (GMF).
Ingegneria del Software 2 – Riuso del Software
35
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 (v. Android)
Si differenziano dai design patterns per il fatto di
essere astrazioni di livello più alto, a livello
architetturale anzichè di design.
Ingegneria del Software 2 – Riuso del Software
36
18
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
Ingegneria del Software 2 – Riuso del Software
37
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
Ingegneria del Software 2 – Riuso del Software
38
19
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, …)
Ingegneria del Software 2 – Riuso del Software
39
Model-view-controller
Input
utente
Stato del Controller
Messaggi
di modifica
della View
Metodi del controller
Stato della View
Metodi della View
Stato del Model
Modifiche
al Model
Metodi del Model
Interrogazioni e
aggiornamenti
del Model
Schema del Framework Model-View-Controller
Ingegneria del Software 2 – Riuso del Software
40
20
MVC - come funziona
•
L’utente interagisce con la UI scatenando eventi (es. click su un
elemento della UI)
•
Il Controller interviene gestendo l’evento mediante un handler o
un callback
Il Controller notifica la richiesta utente al Model, causando un
eventuale cambiamento di stato del Model
La View interroga il Model per generare una nuova interfaccia
utente
– La view viene notificata del cambiamento direttamente dal
Controller, oppure indirettamente mediante il pattern
Observer
•
•
Ingegneria del Software 2 – Riuso del Software
41
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
Ingegneria del Software 2 – Riuso del Software
42
21
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
Ingegneria del Software 2 – Riuso del Software
43
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
Ingegneria del Software 2 – Riuso del Software
44
22
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
• E’ opportuno negare l’accesso alle funzionalità non utilizzate
• Può essere conveniente economicamente scegliere l’adozione
di COTS più ridotti
Ingegneria del Software 2 – Riuso del Software
45
Esempio: realizzare un sistema di
acquisto basato su COTS
•
•
•
Una organizzazione vuole dotarsi di un sistema per
consentire a tutti I suoi dipendenti di effettuare ordini
dai propri PC
–
Il dipendente deve poter cercare liberamente gli articoli
sul Web e fare ordini (e-commerce)
–
la gestione degli ordini deve essere eseguita in modo
centralizzato da un unico Ufficio Ordini
L’organizzazione possiede già un sistema COTS per
gestire ordini ed uno per la fatturazione e consegna
(usato solo dall’ufficio ordini).
Si sceglie di costruire il nuovo sistema integrando
tale COTS con altri componenti.
Ingegneria del Software 2 – Riuso del Software
46
23
Dettagli della soluzione
• Sul lato client, saranno usati programmi standard di
e-mail e web browsing (per eseguire la ricerca degli
articoli da ordinare).
• Sul server, si integrerà una piattaforma per l’ecommerce con il sistema pre-esistente (ordini e
fatturazioni).
– 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.
Ingegneria del Software 2 – Riuso del Software
47
Esempio: Sistema Acquisti basato su
COTS
Client
Client
Clientdidiposta
posta
elettronica
elettronica
Browser
Browserweb
web
Server
Sistema
Sistemadidi
e-commerce
e-commerce
Adattatorez
Sistema
Sistemadidi
Posta
Postaelettronica
elettronica
Sistema
SistemaOrdini
Ordiniee
Fatturazioni
Fatturazioni
Adattatore
Un esempio di sistema basato su COTS
Ingegneria del Software 2 – Riuso del Software
48
24
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
Sistema
Sistema11
Adattatore
Sistema
Sistema22
– L’Adattatore ha il compito di eseguire le necessarie
trasformazioni di formato dei dati
• Quali approcci e tecnologie sono usabili?
Ingegneria del Software 2 – Riuso del Software
49
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[1], note le rispettive
grammatiche, si può scrivere un documento XSLT[2]
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 [3]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 [4] o JavaCC[5])
•
•
Ingegneria del Software 2 – Riuso del Software
50
25
Problemi dei COTS (1/2)
• 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.
Ingegneria del Software 2 – Riuso del Software
51
Problemi dei COTS (2/2)
• 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.
Ingegneria del Software 2 – Riuso del Software
52
26
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.
Ingegneria del Software 2 – Riuso del Software
53
Possibili specializzazioni
•
Specializzazione della piattaforma
–
•
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 per diversisistemi
operativi o hardware, senza modificare le funzionalità
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
Ingegneria del Software 2 – Riuso del Software
54
27
Configurazione
•
•
Può avvenire in due momenti diversi:
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: Enterprise
Resource Planning)
•
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
Ingegneria del Software 2 – Riuso del Software
55
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.
Ingegneria del Software 2 – Riuso del Software
56
28
Organizzazione di un Sistema ERP
Strumento per
pianificare
la configurazione
Generico Sistema ERP
Database
Della
Configurazione
Database
Del Sistema
Ingegneria del Software 2 – Riuso del Software
57
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.
Ingegneria del Software 2 – Riuso del Software
58
29
Esempio :un generico sistema di gestione
risorse
Livello UI
Interfaccia Utente
Autenticazione
Utente
Consegna
Risorse
Gestione
Risorse
Gestione
Query
Controllo Politica
delle Risorse
Livello di Gestione
I/O
Allocazione
Risorse
Livello Risorse
Gestione Transazioni
Database Risorse
Livello Database
Ingegneria del Software 2 – Riuso del Software
59
Una istanza del sistema generico:
Il sistema invio veicoli
Comms system
inter face
User interface
Operator
authentication
Vehicle status
manager
Equipment
database
Map and route
planner
Report
generator
Query
manager
Equipment
Vehicle
despatcher manager
Incident
logger
Transaction management
Vehicle database
Ingegneria del Software 2 – Riuso del Software
Vehicle
locator
Incident log
Map database
60
30
Processo di Sviluppo di una nuova
applicazione (da una famiglia di prodotti)
Nuova Negoziazione
dei Requisiti
Raccolta dei
Requisiti
Utente
Scelta del
Membro della
Famiglia più attinente
Adattamento
Del sistema esistente
Rilascio di un nuovo
Membro della
Famiglia
Ingegneria del Software 2 – Riuso del Software
61
Le fasi del processo di sviluppo
•
Raccolta dei requisiti Utente
–
•
Scelta del Membro della Famiglia più attinente
–
•
Eventuale adattamento dei requisiti per minimizzare le modifiche
Adattamento Del sistema esistente
–
•
Cercare il membro della famiglia di prodotti che è più vicino al
prodotto richiesto
Nuova Negoziazione dei Requisiti
–
•
Individuare I requisiti degli utenti attraverso la presentazione del
sistema esistente, evidenziando le modifiche necessarie
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)
Ingegneria del Software 2 – Riuso del Software
62
31