Component Based Software Engineering (CBSE

Transcript

Component Based Software Engineering
(CBSE)
Riferimenti:
I.Sommerville, Ingegneria del Software, 8°
edizione- Cap. 19
Ingegneria del Software 2 – Component Based Software Engineering
1
Outline
• Componenti e modelli di componenti
• Il processo CBSE
• La composizione dei Componenti
2
1
CBSE (Component Based Software
Engineering)- premessa
•
Il CBSE nasce alla fine degli anni ’90 come approccio per lo
sviluppo software basato sul riuso in cui:
– il riuso è più semplice ed immediato di quello praticabile in sistemi
Object-Oriented
•
Nello sviluppo O.O. il riuso è a livello di singole classi di oggetti.
– Le classi di oggetti possono essere troppo dettagliate e specifiche per
consentirne un efficace riuso.
– È richiesta una conoscenza approfondita delle classi per poterle
riusare (necessità di disporre del codice sorgente).
•
Nel CBSE invece il riuso è basato su componenti che sono più
astratti delle classi di oggetti
– non è richiesta la conoscenza della loro implementazione per
riusarli
– possono essere considerati come fornitori di servizi stand-alone
3
Riuso di Componenti: alcuni esempi…
4
2
Quali proprietà per il componente?
• Un componente è un modulo software che incapsula
funzioni e dati e deve essere riusabile (per la
realizzazione di altri sistemi) e sostituibile (con un
componente equivalente).
• In pratica, deve essere pluggable !
• A tal fine deve :
–
–
–
–
Avere una interfaccia ben definita
Rappresentare una precisa astrazione
Avere alta coesione interna
Avere lasco accoppiamento con l’esterno
5
Sostituibilità del componente
• Due modi di realizzare la sostituibilità (a deploy-time
o a design-time)
– A deploy-time (late composition) non è richiesta la
ricompilazione del sistema
• In entrambi i casi, il sistema complessivo non deve
essere modificato per effetto della sostituzione.
• In generale, un componente B può sostituire un
componente A se:
– B fornisce almeno le stesse caratteristiche di A
– B non richiede più risorse di quelle richieste da A
6
3
Attenzione
• Un componente non opera in totale isolamento!
• La sostituibilità di un componente dipende anche
dall’architettura del software complessivo e dalle
scelte di progetto qui realizzate
• E’ possibile sostituire i componenti restando
nell’ambito di architetture simili con:
– Stessi pattern architetturali
– Stesse gestioni di errori ed eccezioni
– Stessa gestione delle basi di dati , etc. …
7
Elementi essenziali del CBSE
•
Componenti indipendenti, interamente specificati dalle proprie
interfacce
–
•
Standard di descrizione e realizzazione dei componenti
–
•
che semplificano l’integrazione tra componenti, anche sviluppati
in vari linguaggi e provenienti da diversi fornitori.
Middleware
–
•
Interfaccia e implementazione devono essere nettamente
separate (nei sistemi a oggetti sono in classi diverse)
che fornisce supporto per l’interoperabilità gestendo, come fa
ad esempio CORBA [Pope], le problematiche di concorrenza,
protezione, gestione delle transazioni
Un processo di sviluppo
–
che sia stato specificamente progettato per avvalersi con
successo di componenti riusabili.
[Pope]: Alan Pope,The CORBA Reference Guide, Addison Wesley Publishing Company, 1997
8
4
CBSE e principi di progettazione
• Oltre che sul riuso, CBSE si basa su altri ben noti
principi di ingegneria del software:
– I Componenti devono essere indipendenti in modo da
non interferire tra loro;
– Le implementazioni dei Componenti sono nascoste;
– La comunicazione avviene attraverso ben precise
interfacce;
– L’infrastruttura dei Componenti fornisce una
piattaforma che riduce I costi di sviluppo.
9
Problemi
•
•
•
•
Fiducia nei componenti – il componente viene utilizzato a
scatola chiusa (black box); come possiamo fidarci del
fatto che non abbia suoi problemi intrinseci e non
documentati?
Certificazione dei componenti – per garantire sulla
qualità dei componenti sarebbe necessaria una
certificazione di qualità garantita da una terza parte che
se ne assuma la responsabilità
Previsione delle proprietà emergenti – I componenti
potrebbero introdurre dei vincoli e dei problemi che, data
la loro natura opaca, non risultano prevedibili in fase di
scelta del componente nè vengono rilevati in fase di
testing del componente
Compromesso tra i requisiti – Non è sempre possibile
scegliere componenti che risolvano esattamente i nostri
problemi
10
5
Definizioni di Componenti
•
Councill and Heinemann [Cou2001]:
–
•
A software component is a software element that
conforms to a component model and can be
independently deployed and composed without
modification according to a composition standard.
Szyperski [Szy2002]:
– A software component is a unit of composition with
contractually specified interfaces and explicit context
dependencies only. A software component can be
deployed independently and is subject to composition
by third-parties.
[Cou2001].Definition of a Software Component and its elements. In Component Based Software Engineering
(Councill e Heinemann eds) Boston-Addison Wesley. 2001
[Szy2002] Szyperski ,Component Software: Beyond Object-Oriented Programming, 2 ed..Addison Wesley. 2002
11
Componente come fornitore di servizi
•
Quando un sistema necessita di alcuni servizi, chiama un
componente che glieli fornisce, senza sapere:
–
–
•
•
•
Dove il componente viene eseguito
In quale linguaggio è stato sviluppato.
Ne consegue che:
I componenti dovrebbero essere entità indipendenti e
direttamente eseguibili (ovvero compilate prima di essere
riusate)
I servizi offerti dai componenti sono disponibili attraverso
un’interfaccia e tutte le interazioni col componente devono
avvenire attraverso l’interfaccia.
12
6
Riassunto delle Caratteristiche dei
componenti
Standardizzato
La standardizzazione implica l’aderenza del
componente ad un modello standard che ne
definisce interfacce, meta-dati, documentazione,
composizione e consegna.
Indipendente
Un componente dovrebbe essere indipendente da
altri, per poterlo comporre e consegnare privo di
altri componenti. Altrimenti, le dipendenze devono
essere esplicitamente documentate.
Componibile
Per essere componibile, le sue interazioni con
l’esterno devono avvenire solo attraverso
interfacce pubbliche. Deve inoltre fornire all’esterno
informazioni su se stesso, come sui suoi attributi e
metodi.
13
Caratteristiche dei componenti
Consegnabile
Per essere consegnabile, il componente deve
essere autonomo e deve poter operare su una
piattaforma che implementi il suo modello. Ciò
implica che il componente è solitamente in
binario e viene compilato solo all’atto della
consegna.
Documentato
I componenti devono essere documentati in
modo che i potenziali utenti possano decidere
se essi soddisfano le loro necessità: deve
essere documentata sia la sintassi che (in
teoria) la semantica delle interfacce.
14
7
Esempi di sistemi a componenti
•
•
•
•
Sistemi a Plugin
Un plugin è un componente che può essere facoltativamente
aggiunto ad un sistema esistente al tempo di esecuzione, per
estenderne le funzionalità
Usando architetture basate su plugin, è possibile ottenere
sistemi software incrementalmente, aggiungendo nuovi
componenti al nucleo iniziale.
Un esempio: Eclipse
– È una piattaforma che fornisce un motore per implementare
sistemi che sono estensioni della piattaforma stessa,
attraverso l’uso di plugins
– Esistono innumerevoli plugins sviluppati per Eclipse, e
progetti open source basati su esso [Ecl]
15
Altri esempi di sistemi a plugin
•
•
•
•
•
•
L’ambiente integrato per sviluppatori Java ‘NetBeans’
Il Browser Google Chrome
Il browser Mozilla
Il music player Nullsoft Winamp
Il model checker Bogor
…
16
8
Interfacce dei Componenti
•
Fornisce (provides) un’interfaccia
–
•
Con la quale vengono definiti i servizi che esso è in
grado di fornire agli utilizzatori o ad altri componenti.
Richiede (requires) interfacce
–
Specifica quali debbano essere le interfacce di altri
componenti dei quali ha bisogno per poter fornire i
propri servizi.
• Un componente non deve necessariamente essere
indipendente, ma, piuttosto, devono essere note tutte
le sue dipendenze da altri servizi
17
Interfaccia di un componente
Interfaccia
‘Fornisce’
Interfaccia
‘Richiede’
Componente
Definisce i servizi che
Il componente offre ad altri
componenti
Definisce i servizi
che il componente
richiede ad altri
componenti
dell’ambiente
Fig. 1 Rappresentazione grafica UML di un Componente e delle sue Interfacce
18
9
Esempio: componente ‘Data Collector’ per
raccogliere dati da un insieme di sensori
Interfaccia
Richiede
Interfaccia
Fornisce
addSensor
removeSensor
startSensor
sensorManagement
Data collector
sensorData
stopSensor
testSensor
initialise
report
listAll
Fig. 2 Un esempio di Componente e delle sue Interfacce
19
Differenze tra componenti e oggetti…
•
Anche le classi di oggetti hanno metodi che somigliano ai
metodi delle interfacce dei componenti, ma …
•
I componenti sono entità consegnabili
–
•
I componenti non definiscono tipi
–
•
Non devono essere compilati all’interno di un programma
applicativo, ma sono installati su una piattaforma di
esecuzione
Un componente è da vedersi come un’istanza, non come
un tipo da istanziare
I componenti sono opachi
–
La loro implementazione interna non è visibile
all’utilizzatore
20
10
Differenze tra componenti e oggetti
• I componenti sono indipendenti dal linguaggio
– I componenti non devono essere necessariamente sviluppati
in un linguaggio object-oriented
• I componenti sono standardizzati
– La loro implementazione deve rispettare specifici modelli di
componenti
21
Modelli di Componenti
•
Si tratta di standard che definiscono come possa essere
implementato, documentato, distribuito un componente.
•
Esempi:
–
–
–
•
Modello EJB (Enterprise Java Beans)[Ejb]
Modello COM+ (.NET model) [Com+]
Modello Corba (di OMG) …
Il modello di componente specifica vari aspetti, ed in
particolare quali elementi debbano essere definiti nella
interfaccia del componente e come debbano essere scritti.
22
11
Elementi di un modello di componenti
tratto da Weinreich R. e Sametinger J., Component Models and Component
Services: Concepts and Principles, 2001, Addison Wesley, pp. 33-48.
Customisation
Naming
convention
Composition
Interface
definition
Specific
inter faces
Interfaces
Documentation
Meta-data
access
Usage
information
Packag ing
Evolution
suppor t
Deployment
and use
Component model
Fig. 3: Elementi del modello di Componente proposto
23
Alcuni elementi di un modello di
componenti
•
Definizione delle interfacce
–
–
–
Il modello deve specificare come definire le interfacce
ed i suoi elementi (es. nomi delle operazioni,
parametri, ed eccezioni), nonchè vincoli da soddisfare
per l’uso delle interfacce
Necessità di appositi linguaggi per la descrizione
delle interfacce e del loro significato
CORBA e COM+ prevedono appositi linguaggi per la
descrizione delle interfacce (IDL); EJB usa Java
24
12
Alcuni elementi di un modello dii
componenti
•
Composition
–
–
Il modello deve descrivere le modalità secondo le
quali un componente può essere composto con altri
In genere due meccanismi di composizione:
• Modello Client/ server -> invocazione di metodi
• Modello publish/ subscribe
•
Interfacce specifiche
–
Alcuni modelli prevedono che ogni componente
abbia interfacce specifiche (es. Per gestione
protezione e delle transazioni)
25
Alcuni elementi di un modello di
componenti
•
Convenzioni sui nomi e Meta-dati
–
–
–
•
Ogni componente deve avere un nome che ne consenta
l’identificazione univoca, pertanto il modello deve definire
le modalità di identificazione del componente
In CORBA e COM+ ogni classe ha un suo identificatore
(handle) a 128 bit che la rende unica
In EJB invece si utilizza una convenzione basata
sull’indirizzo web del produttore
I meta-dati del componente descrivono il significato del
componente e delle sue interfacce
–
Il modello dei componenti definisce le regole di
descrizione dei meta-dati e come I meta-dati possono
essere interrogati
26
13
Alcuni elementi di un modello dii
componenti
•
Customization
–
Il modello deve descrivere le modalità secondo le
quali un componente può essere adattato dal
cliente, prima di usarlo
• Si usano apposite interfacce per la customization
•
Packaging
–
Definisce come deve essere impacchettato il componente
affinchè possa essere rilasciato (installato e configurato)
nella infrastruttura dei componenti
27
Implementare il modello di componenti
•
I modelli di componenti definiscono anche le caratteristiche del
middleware che deve fornire il supporto per l’esecuzione dei
componenti.
•
L’infrastruttura fornirà:
– Servizi di piattaforma, i quali consentono la comunicazione tra
componenti conformi al modello
• Ad esempio,CORBA è una piattaforma di servizi che permettono la
comunicazione tra componenti realizzati indipendentemente
– Servizi orizzontali, indipendenti dall’applicazione e a disposizione
di altri componenti
•
Per usare i servizi dell’infrastruttura, I componenti vengono
consegnati in un contenitore predefinito e standardizzato (un
insieme di interfacce usate per accedere alle implementazioni
dei servizi di supporto)
28
14
Servizi offerti dall’implementazione del
modello di componente
Horizontal services
Component
management
Transaction
management
Resource
management
Concurrency
Persistence
Security
Platform services
Addressing
Interface
definition
Exception
management
Component
communications
29
Un semplice esempio di implementazione
di un modello di componenti
• Un Sistema Operativo è l’esempio più semplice di
infrastruttura per l’esecuzione di componenti (ossia di
applicazioni)
•
•
Il SO offre:
– Un ambiente per l’esecuzione delle applicazioni e la gestione di
risorse condivise
– i servizi di base di memory management, file management,
inter-process communication, process synchronization, e
security.
Per usare i servizi offerti dalla piattaforma sono necessarie le
interfacce verso i servizi
– Nei SO tali interfacce sono date dalle application programming
interfaces (APIs).
30
15
Limiti del modello di componenti del SO
• Questo primo modello di componenti era
insoddisfacente riguardo alle possibilità di:
– riusare le applicazioni (poco riusabili, in quanto troppo
complesse)
– Comporre le varie applicazioni (che in genere lavorano in
isolamento)
– Offrire servizi specifici di dominio
31
Un altro esempio: il Modello a
Componenti dei plug-in di Eclipse
•
Eclipse è una piattaforma estendibile per costruire ambienti IDE.
•
Fornisce un nucleo di servizi di base per controllare un insieme
di strumenti a supporto della programmazione.
È possibile sviluppare ulteriori strumenti sotto forma di
componenti detti Eclipse plug-ins, che devono rispettare le
norme di contratto della piattaforma Eclipse.
Tali componenti vengono configurati all’interno del sistema al
momento del deploy.
Ogni nuovo componente viene realizzato estendendo il
comportamento di plug-in esistenti.
•
•
•
32
16
Un esempio di file manifest XML per
la descrizione di un plug-in
<?xml version="1.0" encoding="UTF-8"?>
<plugin name="JUnit Testing Framework"
id="org.junit" version="3.7" providername="Eclipse.org">
<runtime>
<library name="junit.jar">
<export name="*"/>
</library>
</runtime>
</plugin>
Al momento del deploy di
un plug-in viene creato il
relativo manifest file (che
viene parsato e caricato in
un registro di plug-in).
Tutti i plug-in vengono
installati in una sottocartella della cartella
plugin.
Il run-time di Eclipse
istanzia i vari plug-in di
cui esiste un manifest file.
•
•
33
Il runtime di Eclipse fornisce una infrastruttura per supportare
l’attivazione e l’esecuzione dei vari plug-in.
Tale infrastruttura si basa su due classi:
– plug-in runtime class
– plug-in class
•
All’interno di una esecuzione di Eclipse, i plug-in vengono
incapsulati in una istanza di una delle due classi
•
La classe plug-in in Eclipse estende
org.eclipse.core.runtime.Plugin, che è una classe astratta che
fornisce metodi per gestire i plug-in.
•
V. http://www.eclipse.org/articles /Article-Plug-inarchitecture/plugin_architecture.html
34
17
Un esempio di estensione di plug-in
L’host plug-in è: la UI
di Eclipse
Il plug-in che estende tale UI
è una UI di help (che fornisce due
Nuove voci menu: HelpContent
e SearchPage).
Sono anche riportate le classi che
Implementano le relative
azioni di callback
35
Come ottenere i componenti riusabili?
Due possibili opzioni
• Procurarsi il componente sul mercato dei componenti
riusabili
– È praticabile per ora solo in ambiti ben definiti
– È una pratica poco diffusa, per il mancanza di fiducia verso
componenti di terze parti
• Produrre i componenti all’interno delle società
produttrici a partire da software esistente.
– I componenti sviluppati per una specifica applicazione non
sono automaticamente riusabili, ma devono essere
generalizzati.
– Come scegliere il componente da rendere riusabile?
36
18
Sviluppo di componenti per il riutilizzo:
fattori da considerare
•
Un componente riusabile deve avere alta probabilità
di essere riusato :
–
–
•
Un componente è più riusabile se è associato ad una
stabile astrazione di dominio (business object).
Ad esempio, in un dominio ospedaliero, le astrazioni
stabili saranno: infermieri, pazienti, trattamenti, etc.
I costi per renderlo riusabile devono essere inferiori a
quelli necessari per risvilupparlo .
–
–
–
Costi di documentazione del componente
Costi di convalida
Costi per renderlo pù riusabile
37
Valutazione dei Costi delle Modifiche
• Le modifiche per rendere riusabile un componente
devono conferire ad esso tutte le proprietà attese da
un componente riusabile, ossia:
– Deve nascondere la rappresentazione interna del proprio
stato;
– Essere indipendente da qualunque altro componente:
• In alternativa, le eventuali dipendenze devono comunque essere
dichiarate
– Essere robusto rispetto a tutti I possibili utilizzi compatibili
con l’interfaccia pubblicata
• Per rendere un componente riusabile bisogna estendere il testing a
tutti gli utilizzi, non più solo a quelli previsti dal modello dei casi d’uso
dell’applicazione originale
• In particolare, deve essere in grado di gestire correttamente tutte le
eccezioni che possono verificarsi
38
19
Possibili modifiche per rendere
riusabile un componente
•
Nascondere/eliminare i metodi specifici dell’applicazione
•
•
•
Rendere i nomi più generali
Aggiungere metodi per aumentare la copertura funzionale
Rendere la gestione delle eccezioni consistente con tutti gli
utilizzi possibili
– In realtà le eccezioni dovrebbero sempre essere
notificate nella risposta, in modo da demandarne la
gestione al chiamante
Aggiunta di una interfaccia di configurazione
Integrare (se possibile) i componenti da cui si dipende
•
•
39
Usabilità e riusabilità di un componente
• Per raggiungere maggiore riusabilità, spesso l’interfaccia
del componente viene resa più complessa,
• Ne può però conseguire la minore usabilità del
componente!
– Se l’interfaccia è troppo complessa, può essere più difficile
da usare
40
20
Trade-off tra usabilità e riusabilità dei
componenti
• Un componente dall’interfaccia semplice non è in grado di
modellare un concetto generale
– Ma è più facile usarlo, comprenderlo
• Un componente dall’interfaccia complessa può modellare
un concetto generale, fornendo tutte le interfacce richieste
alle diverse tipologie di utlizzatori
– Ma è più difficile da comprendere/ usare
– È molto difficile renderlo robusto
– Inoltre potrebbe essere necessario integrarlo con molti altri
componenti
• Necessità di un compromesso!
41
Ottenere componenti da Legacy system
•
Spesso è possibile estrarre componenti riusabili da
sistemi esistenti (“legacy”)
•
Per riutilizzare tali componenti è necessario sviluppare
componenti wrapper che implementino le interfacce
richieste e fornite dal componente riusabile
•
In generale, quest’opportunità è abbastanza costosa ma
può rappresentare una via percorribile quando si
vogliono riutilizzare componenti per le quali è richiesta
una grande affidabilità (e che non si vuole riscrivere)
–
Esempio: componenti che permettono di eseguire
transazioni bancarie
42
21
Sforzo di produzione di componenti riusabili
•
Produrre componenti riusabili è certamente più
oneroso che produrre componenti che non lo siano
–
•
Ma lo sforzo extra potrà essere ricompensato ogni
volta che quel componente verrà riusato anzichè
riscritto (o adattato a partire da un componente
esistente ma non direttamente riusabile)
La vita dei componenti può essere parecchio più
lunga della vita del sistema di cui fa originalmente
parte
43
Il Processo di sviluppo basato su
componenti (CBSE)
• Che tipo di processo di sviluppo può essere adottato
quando si riusano componenti software?
– L’approccio a cascata è impraticabile (v. Bohem)
• Troppa distanza fra la fase di definizione delle specifiche
e quella di integrazione dei componenti
– L’approccio evolutivo non è adatto
• La possibilità di aggiungere nuove feature su richiesta
non è sempre realizzabile con Componenti
preconfezionati (di cui non si possiede il codice)
• É necessario proporre un processo ad-hoc
44
22
Il Processo di sviluppo basato su
componenti (CBSE)
• Quando si riusano componenti software, è essenziale
un compromesso fra requisiti ideali e servizi
effettivamente forniti dai componenti disponibili .
• Di conseguenza, nel processo di sviluppo bisognerà:
– Preparare una prima bozza dei requisiti (molto generici);
– Cercare I componenti e quindi modificare I requisiti in base
alle funzionalità disponibili;
– Cercare ancora, dopo la definizione dell’architettura,
eventuali altri componenti che soddisfano meglio i requisiti
modificati.
– Lo sviluppo richiederà l’integrazione dei componenti e
sviluppo di glue-code
45
Processo CBSE
Raccolta dei
Requisiti
Utente
Identificazione di
Componenti candidati
Identificazione di
Componenti candidati
Ricerca nuovi
Componenti
Scelta dei
Componenti
Modifica dei
Requisiti in base ai
Componenti disponibili
Integrazione dei
Componenti
Progetto
Architetturale
Sistema
Convalida dei
Componenti
46
23
La ricerca dei componenti
•
•
In genere la ricerca avviene con approcci informali
Sarebbe necessario definire approcci meglio formalizzati alla
ricerca, basati su:
– Tecniche di classificazione dei componenti
• Es. tecniche basate su tassonomie e ontologie
• Tecniche di machine learning
• Tecniche basate su misure di distanza semantica fra
componenti richiesti e disponibili
– Tecniche di clustering (uso di metriche di somiglianza)
– …
– Vedere:
• S. Mahmood, R. Lai and Y.S. Kim, Survey of component-based
software development, IET Softw., 2007, 1, (2), pp. 57–66
47
La Convalida dei componenti creati
•
Bisogna valutare se i componenti realizzati coprono
effettivamente tutti i requisiti richiesti e si
comportano come annunciato
–
–
A seconda del fornitore, può essere necessario anche il
test dei singoli componenti, oltre che dell’integrazione
La specifica dei componenti deve essere tale da fornire le
informazioni necessarie per poter costruire una test suite
(e un ambiente di test per eseguirla) che sia in grado di
verificarne tutte le funzionalità
• Nella pratica però la specifica è solo informale…
–
L’utilizzo di un preciso formalismo di specifica può
consentire l’utilizzo di strumenti che generino
automaticamente casi di test
48
24
Convalida dei requisiti di qualità
• I componenti realizzati devono garantire I requisiti di
qualità previsti, primi tra tutti quelli di sicurezza .
• Anche se un componente è stato testato e funziona
bene in un ambito operativo, nuovi problemi possono
sorgere quando si cambia l’ambito
– impossibile testare il componente in ogni possibile
ambito…
49
Un esempio: il fallimento della missione
Ariane 5
•
Nel 1996, il razzo Ariane 5 si distrusse durante il
primo test di volo poichè il sistema ne perse il
controllo dopo 37 secondi
•
La causa del problema risiedeva in un componente
riusato dal software di Navigazione Inerziale
sviluppato per Ariane 4
–
–
In particolare, il problema fu causato da una eccezione di
overflow non gestita, la quale però non poteva verificarsi
nell’Ariane 4, a causa della ridotta potenza rispetto al 5
La funzione che diede errore non era stata testata perchè
non richiesta in Ariane 5 (e non era inserita fra I requisiti)
50
25
Fase di Integrazione
• I componenti selezionati saranno integrati :
– Con nuovi componenti sviluppati ad hoc
– Tra di loro
– Con l’infrastruttura di supporto ai componenti fornita
• L’nfrastruttura fornisce servizi per la comunicazione fra i
componenti e servizi orizzontali (servizi per le UI,
gestione transazioni, protezione, concorrenza,etc.)
51
Composizione di componenti
•
I componenti più semplici risultano essere i più riusabili ma non
riescono a risolvere problemi complessi
–
•
•
Una composizione di componenti può raggiungere requisiti
più specifici e complessi
La composizione dei componenti è un processo che consente di
ottenere un sistema attraverso l’assemblaggio di componenti
Un problema della composizione: può essere necessario
scrivere del codice integratore (glue code) per:
– Rendere compatibili i formati degli input e degli output dei
vari componenti
–
Coordinare i vari componenti
52
26
Tipologie di composizione-1
• Composizione Sequenziale
– Nel componente composto, i componenti costituenti
sono eseguiti in sequenza
– Richiede lo sviluppo di un glue code per realizzare
correttamente la sequenza
– Esempio:
A
B
– Il glue code invoca correttamente A e B in sequenza
53
Tipologie di composizione- 2
• Composizione Gerarchica
– Nel componente composto, un componente invoca
direttamente i servizi dell’altro componente
– Esempio:
A
B
Non c’è glue code: la classe
generale chiama I metodi di
quella specializzata e ne
espone altri
– Il componente A invoca B direttamente
54
27
Tipologie di composizione- 3
• Composizione Additiva
– Le interfacce di due o più componenti sono usate insieme
per creare un nuovo componente che, complessivamente,
esporta l’interfaccia ottenuta dall’unione di quelle offerte dai
componenti costituenti.
A
B
Dall’esterno viene visto un
componente che fornisce i
servizi di A e di B
55
Incompatibilità tra le interfacce di
componenti
•
Incompatibilità tra i parametri delle operazioni
–
•
Incompatibilità tra operazioni
–
•
Le due interfacce prevedono nomi diversi per la stessa
operazione
Incompletezza delle operazioni
–
•
Operazioni con lo stesso nome accettano un numero
diverso di parametri o parametri di tipo diverso
Operazioni con lo stesso nome svolgono, in realtà l’una
un sottoinsieme delle operazioni dell’altra
Tutti questi problemi di incompatibilità possono essere risolti
dal glue code, in particolare dai cosiddetti Adaptor
56
28
Esempio: componenti incompatibili
string location(string pn)
phoneDatabase (string command)
addressFinder
string owner (string pn)
string proper tyType (string pn)
displayMap (string postCode, scale)
mapDB (string command)
mapper
printMap (string postCode, scale)
- Il componente addressFinder trova l’indirizzo associato ad un numero di telefono (pn) e lo restituisce
come stringa
- Il componente mapper visualizza la mappa dell’area associata ad un dato codice postale (postCode)
57
Componenti Adattatori
•
•
•
Risolvono il problema della incompatibilità delle
interfacce fra componenti.
Gli adattatori possono essere diversi, a seconda del
tipo di composizione .
I componenti addressFinder e mapper possono
essere composti tramite un adattatore che estrae il
codice postale da un indirizzo restituito da
addressFinder e lo passa al componente mapper.
58
29
Composizione tramite un Adattatore
•
Il componente postCodeStripper è l’adattatore
necessario per la composizione di addressFinder e
mapper.
•
Il codice complessivo è:
address= addressFinder.Location(telefono);
postCode=postCodeStripper.getPostCode(address);
Mapper.displayMap(posCode, 10000);
59
Altro esempio di Adapter per il
componente data collector
sensorManagement
addSensor
removeSensor
startSensor
start
sensor
stop
getdata
Adapter
Data collector
sensorData
stopSensor
testSensor
initialise
repor t
listAll
60
30
Semantica delle interfacce
•
Come stabilire se interfacce sintatticamente identiche
corrispondono allo stesso servizio richiesto/fornito?
–
•
In generale bisogna basarsi sulla documentazione del
componente
Esempio:
– Un componente PhotoLibrary vuole fornire i metodi per
prelevare immagini da una fotocamera, etichettarle e
archiviarle in una libreria fotografica
– Interfaccia per il componente PhotoLibrary:
public void addItem (Identifier pid ; Photograph p; CatalogEntry p hotodesc) ;
public Photograph retrieve (Identifier pid) ;
public CatalogEntry catEntry (Identifi er pid) ;
61
Photo library composition
getImage
addItem
Photo
Library
adaptor
retrieve
catEntry
Image
Manager
getCatalogEntry
User
Inter face
62
31
Photo Library documentation
Documentazione di AddItem
“Questo metodo aggiunge una foto alla libreria e
associa ad essa il suo descrittore, fornito
dall’utente”
Domande:
1. Cosa succede se il descrittore è stato già utilizzato?
2. Quando elimino una foto, viene eliminato anche il suo
descrittore dal catalogo?
- Se così non fosse, potrebbe essere considerato non
valido un descrittore che non appartiene più a
nessuna foto
63
OCL
•
•
•
Object Constraint Language (OCL) è un linguaggio
pensato per la definizione di vincoli (constraints)
previsti dai modelli UML
E’ basato sulle nozioni fondamentali di pre e post
condizione
La sua specifica è reperibile all’indirizzo:
–
•
http://www.omg.org/docs/ptc/05-06-06.pdf
Si è rivelato utile anche per la descrizione delle
condizioni di usabilità delle interfacce di un
componente
64
32
Esempio: specifica OCL dell’interfaccia
per photo library
La parola chiave context indica il componente a cui si applica la
condizione
context addItem
Le precondizioni indicano ciò che deve essere vero prima di eseguire
addItem
Pre:
PhotoLibrary.libSize()>0
PhotoLibrary.retrieve(pid)=null;
Le precondizioni indicano ciò che deve essere vero dopo l’esecuzione
Post:
libSize()=libSize()@pre+ 1;
PhotoLibrary.retrieve(pid)=p;
PhotoLibrary.catEntry(pid)=photodescr;
65
Spiegazione delle specifiche OCL
•
Secondo la specifica OCL del componente Photo Library, valgono le
seguenti condizioni per l’interfaccia addItem :
–
–
–
–
–
Non deve esistere nessuna foto nella libreria che abbia lo
stesso identificativo della foto da inserire;
La libreria deve già esistere prima dell’inserimento;
L’inserimento di una nuova foto incrementa la dimensione della
libreria di 1;
Se si effettua una ricerca di una foto con lo stesso identificativo
assegnato, il componente restituisce la foto che è stata
aggiunta;
Se si effettua una ricerca nel catalogo con tale identificativo, si
ottiene il descrittore dell’elemento inserito.
66
33
CBSE: letture consigliate
• S. Mahmood, R. Lai and Y.S. Kim, Survey of
component-based software development, IET Softw.,
2007, 1, (2), pp. 57–66
• Li, Conradi, ..Torchiano, Morisio, Development with
Off-the-Shelf Components: 10 Facts, IEEE Software,
Mar-Apr. 2009, pp. 80-87
67
34

Component Based Software Engineering (CBSE

Transcript

Documenti analoghi

notice to graduating students pc

Component Based Software Engineering (CBSE

Attività

Mobilità e applicazioni per i “runners”.

Bepi Colombo Prize 2008

Avviso conferimento incarico da parte del Dipartimento di

UNIVERSITA` DEGLI STUDI e-CAMPUS FACOLTA` di INGEGNERIA

Ai Dipendenti ASIRobicon S.p.A Oggetto: High Voltage Engineering

Inserite qui il vostro nome e cognome, il nome dell`Università

Errata corrige al Verbale della Commissione per l`esame delle