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 build- to-order one, more akin to plumbing than gun manufacturing. But the principles of standardization and interchangeability pioneered for standard products apply directly to build-to- order 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

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 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 CB Development for Enterprise Systems - Applying the Select Perspective (CUP) Implementazione privata Information hiding + ragioni commerciali Contratto col cliente utilizzatore Una componente serve per comporre

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 & 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 Requisiti non funzionaliRequisiti funzionali Funzionalità offerte e richieste dalla componente 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 Sintassi Nomi e tipi Si sa definire e verificare staticamente Semantica Invarianti, pre e post condizioni Si sanno definire ma non sempre verificare Consiste di due parti: ciò che la componente vuole dal suo ambiente (import) ciò che la componente realizza ed offre all’esterno (export) importimport exportexport

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 Black box in 1 :t 1 in 2 :t 2 in 3 :t 3 out 1 :t’ 1 out 2 :t’ 2 White box in 1 :t 1 in 2 :t 2 in 3 :t 3 out 1 :t’ 1 out 2 :t’ 2 in 1 :t 1 in 2 :t 2 in 3 :t 3 out 1 :t’ 1 out 2 :t’ 2 Grey box Modifiche a in 1 non hanno impatto su out 2

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 in 1 :t 1 in 2 :t 2 in 3 :t 3 out 1 :t’ 1 out 2 :t’ 2 x 1 :t’ 1 x 2 :t’ 2 y:t’ Nuova Componente Stessi tipi e contratti compatibili

Connettori caso più generale Bisogna trasformare l’export di C in modo che vada bene come import di C’  1 :t 1  3 :t 3  2 :t 2 1:11:1 2:22:2 Si deve definire una nuova componente con import = export di C e export = import di C’ in 1 :t 1 in 2 :t 2 in 3 :t 3 out 1 :t’ 1 out 2 :t’ 2 C’ x1:’1x1:’1 x2:’2x2:’2 y1:1y1:1 y2:2y2:2 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”