Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D Le Miniguide all'orientamento Gli eBook di Federica La Corte in Rete
 
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Anna Rita Fasolino » 8.Component Based Software Engineering (CBSE): Il processo di sviluppo CBSE


Outline

  • Il processo CBSE.
  • La composizione dei Componenti.

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;
  • Cercare I componenti e quindi modificare I requisiti in base alle funzionalità disponibili;
  • Cercare ancora eventuali altri componenti che soddisfano meglio i requisiti modificati.

Processo CBSE


La Convalida dei componenti creati

Bisogna valutare se i componenti realizzati coprono 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.

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.

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.

Tipologie di composizione

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 (riportato nella figura a lato).
Il glue code invoca correttamente A e B in sequenza.

Il glue code invoca correttamente A e B in sequenza.


Tipologie di composizione (segue)

Composizione Gerarchica

  • Nel componente composto, un componente invoca direttamente i servizi dell’altro componente;
  • Esempio (riportato nella figura a lato).
Il componente A invoca B direttamente. Non c’è glue code: la classe generale chiama I metodi di quella specializzata e ne espone altri.

Il componente A invoca B direttamente. Non c'è glue code: la classe generale chiama I metodi di quella specializzata e ne espone altri.


Tipologie di composizione (segue)

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.

Dall’esterno viene visto un componente che fornisce i servizi di A e di B.

Dall'esterno viene visto un componente che fornisce i servizi di A e di B.


Incompatibilità tra le interfacce di componenti

Incompatibilità tra i parametri delle operazioni

  • Operazioni con lo stesso nome accettano un numero diverso di parametri o parametri di tipo diverso.

Incompatibilità tra operazioni

  • Le due interfacce prevedono nomi diversi per la stessa operazione.

Incompletezza delle operazioni

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

Esempio: componenti incompatibili

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

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


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.

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);

Altro esempio di Adapter per il componente data collector


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.

Photo library composition


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.

    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 dal sito Web Object Management Group .
    Si è rivelato utile anche per la descrizione delle condizioni di usabilità delle interfacce di un componente.

    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;

    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.

    I materiali di supporto della lezione

    I. Sommerville, Ingegneria del Software, 8° edizione- Cap. 19

    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

    • Contenuti protetti da Creative Commons
    • Feed RSS
    • Condividi su FriendFeed
    • Condividi su Facebook
    • Segnala su Twitter
    • Condividi su LinkedIn
    Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion