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 (CBSE) è un
approccio per lo sviluppo software basato sul riuso.
• Si è affermato a seguito del fallimento dello sviluppo
object-oriented nel supportare un effettivo riuso.
– Le singole classi di oggetti possono essere troppo
dettagliate e specifiche.
• I componenti sono più astratti delle classi di oggetti e
possono essere considerati come fornitori di servizi
stand-alone.
3
Elementi essenziali del CBSE
•
•
•
•
Componenti indipendenti, interamente specificati dalle
proprie interfacce
– Interfaccia e implementazione devono essere nettamente
separate (nei sistemi a oggetti sono in classi diverse)
Standard di descrizione e realizzazione dei componenti
che semplificano l’integrazione tra componenti, anche
sviluppati in vari linguaggi e provenienti da diversi fornitori.
Middleware 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 orientato verso la
realizzazione di componenti riusabili
4
2
CBSE e principi di progettazione
• Oltre che sul riuso, CBSE si basa su 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.
5
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
6
3
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.
7
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.
•
8
4
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.
9
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.
10
5
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
11
Interfaccia di un componente
Requires interface
Defines the services
from the component’s
environment that it
uses
Provides interface
Component
Defines the services
that are provided
by the component
to other components
12
6
Esempio: componente Data Collector
Requires interface
Provides interface
sensorManagement
Data collector
sensorData
addSensor
removeSensor
startSensor
stopSensor
testSensor
initialise
report
listAll
13
Differenze tra componenti e oggetti
•
I componenti sono entità consegnabili
–
•
I componenti non definiscono tipi
–
•
La loro implementazione interna non è visibile all’utilizzatore
I componenti sono indipendenti dal linguaggio
–
•
Un componente è da vedersi come un’istanza, non come un
tipo da istanziare
I componenti sono opachi
–
•
Non devono essere compilati all’interno di un programma
applicativo, ma sono installati su una piattaforma di esecuzione
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
14
7
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 in particolare quali elementi
debbano essere definiti nella sua interfaccia e come debbano
essere scritti.
15
Elementi di un modello di componente
Weinreich e Sametinger, 2001
16
8
Elementi di un modello di componente
•
Definizione delle interfacce
–
•
Convenzioni sui nomi
–
–
•
CORBA e COM+ prevedono appositi linguaggi per la
descrizione delle interfacce (IDL); EJB usa Java
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
Packaging
–
Definisce come deve essere impacchettato il componente
affinchè possa essere usato dagli altri elementi del
middleware
17
Supporto fornito dal middleware
•
•
I modelli di componenti definiscono anche le caratteristiche del
middleware che deve fornire il supporto per l’esecuzione dei
componenti.
L’implementazione di un middleware comprende:
– 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)
18
9
Component model services
Horizontal services
Component
management
Transaction
management
Resource
management
Concurrency
Persistence
Security
Platform services
Addressing
Interface
definition
Exception
management
Component
communications
19
Come procurarsi i componenti riusabili?
• In attesa che si sviluppi un mercato aperto di
componenti riusabili, attualmente questi si ottengono
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.
• Quali fattori guidano la scelta del componente da
rendere riusabile?
20
10
Sviluppo di componenti per il riutilizzo
•
Un componente riusabile deve avere alta
probabilità di essere riusato, ed i costi per renderlo
riusabile devono essere inferiori a quelli necessari
per risvilupparlo.
•
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.
21
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
22
11
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
23
Usabilità e riusabilità di un componente
•
•
Per raggiungere maggiore riusabilità, spesso l’interfaccia del
componente viene resa più complessa.
C’è un fondamentale trade-off tra usabilità e riusabilità dei
componenti:
– Un componente dall’interfaccia semplice non è in grado di
modellare un concetto generale
• Ma è più facile renderlo riusabile
– Un componente dall’interfaccia complessa può modellare un
concetto generale, fornendo tutte le interfacce richieste alle diverse
tipologie di utlizzatori
• Ma è molto difficile renderlo robusto
• Inoltre potrebbe essere necessario integrarlo con molti altri componenti
•
Necessità di un compromesso!
24
12
Legacy system components
•
Spesso si vuole estrarre componenti riusabili da sistemi
esistenti (“legacy”)
•
Per riutilizzare tali componenti è necessario sviluppare un
componente wrapper che implementi le interfacce richieste e
fornite dal componente riusabili
– Ulteriori dettagli verranno presentati a margine delle
problematiche di migrazione e reengineering
•
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
25
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
26
13
Il Processo CBSE
• Quando si riusano componenti, è essenziale un
compromesso fra requisiti ideali e servizi
effettivamente forniti dai componenti disponibili.
• Di conseguenza, bisognerà:
– Sviluppare una prima bozza dei requisiti;
– Cercare I componenti e quindi modificare I requisiti in
base alle funzionalità disponibili;
– Cercare ancora eventuali altri componenti che
soddisfano meglio I requisiti rivisti.
27
Processo CBSE
Outline
system
requirements
Identify candidate
components
Modify
requirements
according to discovered
components
Architectural
design
Identify candidate
components
Compose
components to
create system
28
14
Validazione dei componenti creati
–
Bisogna valutare se i componenti realizzati coprano
effettivamente tutti i requisiti richiesti
–
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à
• L’utilizzo di un preciso formalismo di specifica può
consentire l’utilizzo di strumenti che generino
automaticamente casi di test
–
I componenti realizzati devono garantire I requisiti di
qualità previsti, primi tra tutti quelli di sicurezza
29
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 risiedeva in una
eccezione di overflow non gestita, la quale però
non poteva verificarsi nell’Ariane 4, a causa
della ridotta potenza rispetto al 5
30
15
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
Nell’integrazione di componenti tramite composizione
può essere necessario scrivere del glue code per:
–
Rendere compatibili i formati degli input e degli
output dei vari componenti
Coordinare i vari componenti
–
31
Tipologie di composizione
Sequenziale
A
Gerarchica
Glue Code
A
Glue Code
B
Additiva
B
A
B
Non c’è glue code: la classe
generale chiama I metodi di
quella specializzata e ne
espone altri
Glue Code
Dall’esterno viene visto un
componente che fornisce i
servizi di A e di B
32
16
Incompatibilità tra le interfacce
•
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
33
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)
34
17
Componenti Adattatori
•
•
•
Risolvono il problema della incompatibilità delle
interfacce fra componenti.
Gli adattatori possono essere diversi, a seconda del
tipo di composizione.
Un addressFinder ed un mapper possono essere
composti tramite un adattatore che estrae il codice
postale da un indirizzo e lo passa al componente
mapper.
35
Composizione tramite un Adattatore
•
Il componente postCodeStripper è l’adattatore
necessario per la composizione di addressFinder e
mapper.
•
Il codice dell’Adattatore è:
address = addressFinder.location (phonenumber) ;
postCode = postCodeStripper.getPostCode (address) ;
mapper.displayMap(postCode, 10000)
36
18
Altro esempio di Adapter per il
componente data collector
start
sensor
stop
getdata
sensorManagement
Adapter
addSensor
removeSensor
startSensor
Data collector
sensorData
stopSensor
testSensor
initialise
report
listAll
37
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 biblioteca fotografica
– Interfaccia per il componente PhotoLibrary
public void addItem (Identifier pid ; Photograph p; CatalogEntry photodesc) ;
public Photograph retrieve (Identifier pid) ;
public CatalogEntry catEntry (Identifier pid) ;
38
19
Photo library composition
getImage
addItem
Photo
Library
adaptor
retrieve
catEntry
Image
Manager
getCatalogEntry
User
Inter face
39
Photo Library documentation
Documentazione di AddItem
“Questo metodo aggiunge una foto alla biblioteca
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
40
20
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
41
Descrizione OCL dell’interfaccia per photo library
-- The context keyword names the component to which the conditions apply
context addItem
-- The preconditions specify what must be true before execution of addItem
pre:
PhotoLibrary.libSize() > 0
PhotoLibrary.retrieve(pid) = null
-- The postconditions specify what is true after execution
post: libSize () = libSize()@pre + 1
PhotoLibrary.retrieve(pid) = p
PhotoLibrary.catEntry(pid) = photodesc
context delete
pre: PhotoLibrary.retrieve(pid) <> null ;
post: PhotoLibrary.retrieve(pid) = null
PhotoLibrary.catEntry(pid) = PhotoLibrary.catEntry(pid)@pre
PhotoLibrary.libSize() = libSize()@pre - 1
42
21
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
45
22

Component Based Software Engineering (CBSE

Transcript

Documenti analoghi

notice to graduating students pc

Attività

Mobilità e applicazioni per i “runners”.

Bepi Colombo Prize 2008

Avviso conferimento incarico da parte del Dipartimento di

Component Based Software Engineering (CBSE

UNIVERSITA` DEGLI STUDI e-CAMPUS FACOLTA` di INGEGNERIA

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

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

Errata corrige al Verbale della Commissione per l`esame delle

RIF COD 28303 – NEOLAUREATI IN INGEGNERIA ATS – DIP