Anna Rita Fasolino » 7.Component Based Software Engineering (CBSE): Generalità

Outline

• Componenti e modelli di componenti
• Il processo CBSE
• La composizione dei Componenti

CBSE

Il Component-based software engineering (CBSE) è un approccio per lo sviluppo software basato sul riuso.
Nasce alla fine degli anni ‘90 come proposta per superare I limiti mostrati dall’approccio Object-Oriented nel supportare un riuso semplice ed immediato:

• 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).

I componenti invece sono più astratti delle classi di oggetti, non è richiesta la conoscenza della loro implementazione per riusarli e possono essere considerati come fornitori di servizi stand-alone.

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 stato specificamente progettato per avvalersi con successo di componenti riusabili.

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.

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.

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

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.

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.

Caratteristiche dei componenti (segue)

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.

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.

Interfaccia di un componente

Fig. 1 Rappresentazione grafica UML di un Componente e delle sue Interfacce.

Esempio: componente ‘Data Collector’

Fig. 2 Un esempio di Componente e delle sue Interfacce.

Differenze tra componenti e oggetti

• I componenti sono entità consegnabili
  • Non devono essere compilati all’interno di un programma applicativo, ma sono installati su una piattaforma di esecuzione
• I componenti non definiscono tipi
  • 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
• 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

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.

[Ejb] Specifiche di EJB scaricabili dal seguente sito.
[Com+]: COM+ Specification -Scaricabili dal seguente sito.

Elementi di un modello di componente

Fig. 3: Elementi del modello di Componente proposto in [1].

Alcuni elementi di un modello dei componenti

Definizione delle interfacce

• Il modello deve specificare come definire le interfacce ed i suoi elementi (es. nomi delle operazioni, parametri, ed eccezioni).
• CORBA e COM+ prevedono appositi linguaggi per la descrizione delle interfacce (IDL); EJB usa Java.

Convenzioni sui nomi e Meta-dati

• 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.

Packaging

• Definisce come deve essere impacchettato il componente affinchè possa essere usato dagli altri elementi del middleware.

Supporto fornito dal middleware

I modelli di componenti definiscono anche le caratteristiche del sistema middleware che deve fornire il supporto per l’esecuzione dei componenti.

L’implementazione di un middleware fornisce ai componenti servizi simili e condivisi quali:

• 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).

Servizi offerti dal modello dei componenti

Esempi di servizi orizzontali offerti da un Middleware

• Gestione dei componenti.
• Gestione delle transazioni.
• Gestione delle risorse.
• Concorrenza, Persistenza e Sicurezza.

Esempi di servizi di Piattaforma

• Indirizzamento del componente.
• Definizione delle interfacce.
• Gestione eccezioni.
• Comunicazione fra i componenti.

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?

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.

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.

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

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!

Legacy system components

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.

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.

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: IBM 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].

[Ecl] Eclipse Community Projects and plug-ins.

Altri esempi di sistemi a plugin

• Il Text editor Jedit
• L’ambiente integrato per sviluppatori Java ‘NetBeans’
• Il music player Nullsoft Winamp
• Il browser Mozilla
• Il model checker Bogor
• …