Componenti: concetti generali
Why Components?
What is the motive for producing, distributing,
buying, or using software components?
What are the benefits of component software?
The simplest answer is:
Components are the way to go because all other
engineering disciplines introduced components as
they become mature - and still use them.
Szyperski 1999
Standardized Components Needed
It is easy to see how interchangeable parts could help in
manufacturing. But manufacturing involves replicating a
standard product, while programming does not.
Programming is not an assembly-line business but a buildto-order one, more akin to plumbing than gun
manufacturing.
But the principles of standardization and interchangeability
pioneered for standard products apply directly to build-toorder industries like plumbing. They enabled the markets of
today where all manner of specialized problems can be
solved by binding standardized components into new and
larger assemblies.
Cox 1990
Motivazioni “economiche” delle componenti
• Per una ditta usare un supporto sw è costoso
– Acquisizione e mantenimento
• i costi possono essere abbattuti se si usa sw standard
– Ristrutturazione del lavoro/processo interno per adeguare le procedure a quelle
supportate dal sw
• i costi possono essere abbattuti se si usa sw ad hoc
• Per una ditta usare un supporto sw è utile nella misura in cui li rende
“migliori” delle concorrenti
– Se tutti nel settore usano sw, richiede di avere sw ad hoc ottimizzato
– Autoprodurre del sw è rischioso perché in caso di ritardo sirischia di restare
senza nessun supporto
• Vi è quindi una tensione fra vantaggi e svantaggi di usare sw
standard rispetto a (farsi) produrre un sw ad hoc
• Parziale soluzione: assemblaggio personalizzato (=sw ad hoc) a
partire da componenti standard
Liberamente tratto da Szyperski 1999
Component Market
• Noi ci concentreremo sugli aspetti tecnici ma la
storia dimostra che non sono le soluzioni
tecnicamente migliori che vincono
• Assumendo dati i concetti e la tecnologia perfetta
per le componenti, perché vengono effettivamente
usate bisogna che ce ne sia una massa critica per
creare un mercato
• http://www.componentsource.com/Marketplace/
Componente = ???
• In prima approssimazione “un pezzo di codice che
si può vendere e comporre”
• Deve avere quindi
– Una descrizione di che cosa fa (contratto verso il
cliente)
– Una descrizione di che cosa si aspetta dall’ambiente
– Una realizzazione eseguibile
• Una componente da sola non serve a niente: deve
essere immersa in un ambiente in cui possa essere
(eseguita e) fatta interagire/composta con altre
componenti
Component Definition 1
Contratto col cliente
utilizzatore
Implementazione privata
Information hiding + ragioni commerciali
A component is an executable unit of code that provides
physical blackbox encapsulation of related services.
Its services can only be accessed through a consistent,
published interface that includes an interaction standard.
A component must be capable of being connected to other
components (through a communication interface) to form a
larger group
P. Allen & S. Frost 1998
Una componente serve
per comporre
CB Development for Enterprise Systems Applying the Select Perspective (CUP)
Component Definition 2
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.
ECOOP 1996,
Workshop on Component-oriented Prog. 1997
& Clemens Szyperski
Componente in isolamento
Due aspetti
• Interfaccia con il resto del sistema
• La realizzazione (o implementazione o body)
Non necessariamente aspetti separati come prodotti
(files)
Non necessariamente realizzati
“indipendentemente”
– eg caso (molto particolare) di componente composta
da un solo oggetto parte dell’interfaccia può essere
derivata dalla definizione di classe
Interfaccia
Consiste di due parti:
ciò che la componente vuole dal suo ambiente (import)
ciò che la componente realizza ed offre all’esterno (export)
Requisiti funzionali
i
m
p
o
r
t
Funzionalità offerte e richieste
dalla componente
Sintassi
Nomi e tipi
e
x
p
o
r
t
Si sa definire
e verificare
staticamente
Semantica
Invarianti,
pre e post
condizioni
Si sanno
definire ma
non sempre
verificare
Requisiti non funzionali
Proprietà legate ai tempi di
esecuzione, affidabilità,
robustezza, sicurezza,
disponibilità, risorse minime
richieste o massime utilizzate
etc.
Il più delle volte si esprimono
solo informalmente
Implementazione: black box
• L’uso di una componente è esclusivamente basato
sulla sua interfaccia
• Dal punto di vista dell’utente di una componente
non serve conoscerne l’implementazione
• L’implementazione resta quindi privata del
produttore
– Può essere cambiata senza impatto sul resto del
sistema
– Il codice (algoritmo etc) resta proprietà intellettuale
dell’autore
Dal punto di vista dell’utente una componente è una
scatola nera (black box) di cui si conosce solo il
comportamento in un dato contesto
Implementazione: white box
• Per produrre una componente il progettista deve
ovviamente conoscere/partire dall’interfaccia che
è il suo contratto/scopo
• Ma deve anche avere piena visibilità del codice
che sta scrivendo
Dal punto di vista del produttor una componente è
una scatola aperta/trasparente/bianca (white box) di
cui si conosce ogni singolo dettaglio
Cut&Paste NON è Component based
• Il produttore di una componente ha piena visibilità
dell’implementazione solo nel suo ruolo di
produttore
• Se si vuole costruire una nuova componente
basata su una già esistente si hanno due ruoli
– Di produttore della nuova (white box)
– Di utente della vecchia (black box)
• Usare il codice di una componente come
brogliaccio per una nuova NON è component
based development è cut&paste programming
Cut&Paste Programming e riuso
• 70% del lavoro è fatto dopo la prima
installazione quindi il riuso deve aiutare il
mantenimento e non solo la progettazione
iniziale
• Cut & paste aiuta solo nella prima fase perché:
– bisogna leggere e capire il codice iniziale
– bisogna adattare e modificare il codice
originario
– modifiche e miglioramenti (maintenance)
dell’originale non portano benefici al codice
derivato
Implementazione: grey box
• Black box per l’utente e white box per il produttore in
generale, ma ci sono casi in cui l’utente dovrebbe sapere
qualcosa dell’implementazione
• Esempio tipico: l’utente ha modificato parte del sistema
(contesto di uso della componente) e deve fare test per
verificare che tutto funzioni ancora
– Con la visione a black box deve verificare tutte le funzionalità
dell’export
– Se sapesse come dipendono specifiche funzionalità nell’export
da quelle nell’import potrebbe testare solo quelle per cui è
cambiato qualcosa
• Questo approccio intermedio si chiama grey box
• NB se i contratti nelle interfacce funzionassero bene non
ci sarebbe alcun bisogno di fare test, ma solo di verificare
la soddisfazione delle richieste dell’import
Black/grey/white box
White box
Black box
out1:t’1
in1:t1
out1:t’1
out2:t’2
in2:t2
in3:t3
Grey box
out1:t’1
in1:t1
out2:t’2
out2:t’2
in2:t2
in3:t3
Modifiche a in1 non
hanno impatto su out2
in1:t1
in2:t2
in3:t3
Sviluppo di componenti: scenari tipici
Sviluppo di componente “nuova”
• Partendo dalla specifica (interfaccia)
• Usando o no altre componenti
Componentizzazione di software esistente
• Incapsulazione di import/export
• Razionalizzazione/astrazione del codice
Ristrutturazione di sistema legacy in sistema cb
• Analisi del codice “monolitico” e divisione in
pezzi “riusabili”
• Componentizzazione di ciascun pezzo
Utilizzo di componenti
• Idealmente si dovrebbe creare un sistema guidati
– Dai requisiti (sempre)
– Dalle componenti già pronte sul mercato (CBSE)
• In realtà i due modelli producono conflitti perché
le componenti esistenti non sono mai esattamente
quelle che servirebbero
• Soluzione: import ed export di componenti non
sono direttamente connessi, ma ci si mette in
mezzo un connettore
• Parafrasi tipica: adattatore elettrico fra spina e
presa
Connettori caso banale
y:t’
Stessi tipi e
contratti
compatibili
x1:t’1
x2:t’2
Nuova Componente
out1:t’1
out2:t’2
in1:t1
in2:t2
in3:t3
Connettori caso più generale
out1:t’1
out2:t’2
C’
Bisogna
trasformare
l’export di C in
modo che vada
bene come import
di C’
in1:t1
b1:t1
in3:t3
in2:t2
b2:t2 b3:t3
a1:t1
y1:t1
a2:t2
y2:t2
C
x1:t’1
x2:t’2
Si deve definire
una nuova
componente con
import = export di
C e export = import
di C’
Tipi di connettori
Due tipologie standard di connettori
• Adapter
– modifica l’output di una componente per adattarlo
all’input di un’altra
– adatta una componente pensata per una piattaforma a
funzionare su un’altra
– Parafrasi tipica: convertitore di tensione
• Wrapper
– Incapsula una componente in modo da modificarne
l’interfaccia
– Esempi tipici: aggiunge input che non vengono usati o
nasconde output; mette insieme varie componenti e le
presenta come un’unica componente
Tipi di composizione
• Gli esempi visti sono casi di composizione
gerarchica:
– Due o più componenti vengono composte linkando
output di una ad input di un’altra
– C’è una chiara distinzione fra componente che
fornisce e componente che richiede il servizio
• Ci sono caso più generali in cui le componenti
vengono composte allo stesso livello
– Ciascuna fornisce e richiede servizi dalle altre
– Le componenti cooperano/si coordinano
Implementazione + interfaccia = componente?
• Una stessa interfaccia può essere realizzata da
varie implementazioni (eg vari fornitori)
• La stessa implementazione può essere vista come
realizzazione di diverse interfacce (eg
mascherando alcuni servizi)
• La relazione fra implementazioni e interfacce,
quindi è del tipo “molti a molti”
