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à:
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.
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.
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:
Composizione Sequenziale
Composizione Gerarchica
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.
Incompatibilità tra i parametri delle operazioni
Incompatibilità tra operazioni
Incompletezza delle operazioni
Tutti questi problemi di incompatibilità possono essere risolti dal glue code, in particolare dai cosiddetti Adaptor.
- 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).
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.
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);
Come stabilire se interfacce sintatticamente identiche corrispondono allo stesso servizio richiesto/fornito?
In generale bisogna basarsi sulla documentazione del componente.
Esempio:
Documentazione di AddItem
“Questo metodo aggiunge una foto alla biblioteca e associa ad essa il suo descrittore, fornito dall’utente”.
Domande:
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.
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;
Secondo la specifica OCL del componente Photo Library, valgono le seguenti condizioni per l’interfaccia addItem:
2. Ciclo di Vita e Processi Software
3. Processi per lo sviluppo rapido del software
4. Sviluppo Agile del Software
5. Test Driven Development (TDD)
7. Component Based Software Engineering (CBSE): Generalità
8. Component Based Software Engineering (CBSE): Il processo di svi...
9. Ingegneria del Software orientato ai Servizi
10. Ingegnerizzazione dei Servizi
11. I Processi di Manutenzione del Software
12. Reengineering, Refactoring e Reverse Engineering del Software
13. Verifica e Convalida del Software. Richiami e concetti di base ...
14. Tecniche di Testing Dinamico
15. Testing di Sistemi Object Oriented
16. Automazione del testing e Analisi Mutazionale
17. Tecniche di Analisi Statica del codice e il Debugging
18. Stima dei costi nei progetti Software
19. Il Modello COCOMO per la stima dei costi Software – La gestio...
20. Gestione e Miglioramento dei Processi di Produzione del Softwar...
21. La Valutazione della Qualità dei Processi Software – Il Capa...
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