Concetto: Sviluppo di soluzioni componente
Lo sviluppo basato sui componenti è una variazione dello sviluppo generale di un'applicazione. In questa guida il termine "componente" viene utilizzato per indicare dei componenti sviluppati e distribuibili in modo indipendente.
Descrizione principale
Attività del ciclo di vita:
  1. Introduzione
  2. Attività della fase di inizio
  3. Attività della fase di elaborazione
  4. Attività della fase di costruzione
  5. Attività della fase di transizione
Ulteriori argomenti:

Introduzione

Lo sviluppo basato su componenti è una variazione dello sviluppo generale di un'applicazione in cui:

  • L'applicazione viene assemblata da dei discreti componenti eseguibili che vengono sviluppati e distribuiti in maniera relativamente indipendente gli uni dagli altri, potenzialmente da team diversi.
  • L'applicazione può essere aggiornata tramite incrementi più piccoli, aggiornando solo alcuni dei componenti che compongono l'applicazione.
  • I componenti possono essere condivisi fra le applicazioni, creando non solo delle opportunità di riutilizzo ma anche delle dipendenze all'interno del progetto.
  • Le applicazioni basate su componenti tendono ad essere distribuite, anche se questo non è strettamente correlato all'essere basate su componenti.

In tutta la pagina il termine "componente" viene utilizzato per indicare i componenti sviluppati e distribuibili in modo indipendente. Altrove in RUP, tuttavia, verrà utilizzato il termine "componente" in senso più generale, descritto in Concetto: Componente, e quando necessario, verrà qualificato.

Di seguito viene descritto l'adattamento di RUP (Rational Unified Process) alle sfide dello sviluppo basato sui componenti.

Attività della fase di inizio

Alla fase di inizio viene applicato il flusso di lavoro di base, con le seguenti estensioni o variazioni:

Gestione del progetto

  • Attività: Valutazione dell'ambito del progetto e del rischio
  • Con l'approccio dei componenti, cambia la natura di determinati rischi e ne vengono introdotti di nuovi. Specificatamente:

    • i componenti originati esternamente aumentano i rischi perché introducono degli elementi critici che non sono sotto il controllo diretto del team del progetto
    • i componenti originati esternamente possono ridurre i tempi di sviluppo, diminuendo il rischio risorse
    • i componenti originati esternamente possono alterare l'architettura del sistema, se impongono delle proprie restrizioni strutturali
  • Attività: Pianificazione del progetto
  • Nel Compito: Pianificazione delle fasi e delle iterazioni, il piano per la fase di costruzione può potenzialmente mostrare il progetto suddiviso in due tracce differenti ma parallele: una che sviluppa i componenti specifici per l'applicazione e per il dominio (organizzati nei livelli superiori dell'architettura - consultare Concetto: Livelli) e l'altra dei componenti non specifici per l'applicazione o per il dominio, organizzati nei livelli inferiori. In alcuni casi, i componenti riutilizzabili vengono sviluppati da team di sviluppo gestiti in modo indipendente. La decisione di introdurre delle tracce parallele è principalmente una problema di personale e di risorse, sorta dal desiderio di gestire dei componenti riutilizzabili come beni indipendenti delle applicazioni in cui in cui vengono sviluppati.

Requisiti

Test

Ambiente

  • Attività: Preparazione dell'ambiente per il progetto
  • Quando si raccolgono e si preparano le linee guide del progetto, consultare il  Compito: Preparazione delle linee guida per il progetto per i dettagli tenere in considerazione lo specifico framework componenti ed i vincoli da esso imposti. Le linee guida devono includere come progettare e creare il codice tramite il framework. Devono inoltre fornire una guida per il test relativo alla verifica della conformità sia con lo stesso framework componenti che con le interfacce definite fra i componenti.

Attività della fase di elaborazione

Per la fase di elaborazione viene applicato il flusso di lavoro di base, con le seguenti estensioni o variazioni:

Requisiti

  • Attività: Perfezionamento della definizione del sistema
  • Il Compito: Dettagli dei requisiti software concentra ulteriormente l'attenzione sui requisiti tecnici e non funzionali e sui vincoli imposti ai componenti creati o comprati. I requisiti specifici non funzionali da considerare sono la dimensione, le prestazioni, la quantità di RAM del disco o della memoria, le problematiche runtime inerenti alle licenze e vincoli simili, che influenzano la selezione o la costruzione del componente.

Analisi e progettazione

  • Attività: Progettazione di componenti
  • Il Compito: Progettazione dei sottosistemi perfeziona ulteriormente la progettazione dei componenti, identificando le classi all'interno del componente che forniscono l'effettiva funzionalità del componente. Allo stadio iniziale della fase di elaborazione probabilmente esiste un'unica classe, una specie di 'proxy di sottosistema/componente' che agisce da stub per simulare il funzionamento del componente per la creazione di un prototipo di architettura. In seguito la funzionalità di quella classe viene distribuita ad una collaborazione di classi contenute nel sottosistema. Queste classi contenute sono definite in Compito: Progettazione della classe.

  • Attività: Progettazione del database
  • Il punto focale nell'elaborazione è assicurare che la strategia di persistenza sia scalabile e che il meccanismo di persistenza e la progettazione del database supportino i requisiti di sistema per la produttività. Le classi persistenti vengono identificate ed associate al meccanismo di persistenza. I casi d'uso con molti dati vengono analizzati per verificare che i meccanismi siano scalabili. Oltre alle attività di verifica, il meccanismo di persistenza e la progettazione del database vengono valutati e convalidati.

Implementazione

Test

  • Attività: Definizione della missione di valutazione, Verifica dell'approccio di test, Test e valutazione, Ottenimento della missione accettabile, Miglioramento delle risorse di test

    Le attività di test nella fase di elaborazione si incentrano sulla convalida dell'architettura. Per i sistemi basati su componenti questo si traduce in:

    • utilizzo delle interfacce fra i componenti, per verificare che i confini dei componenti siano appropriati
    • una maggiore attenzione alla verifica delle prestazioni, specialmente test di scalabilità delle prestazioni, per verificare che i volumi di transazione anticipati possano essere sostenuti

    Deve essere valutata anche qualsiasi eventuale assunzione inerente del framework componenti. In genere sono incluse la scalabilità e la produttività dei meccanismi di persistenza e di gestione della transazione, nei quali delle assunzioni nascoste effettuate dal progettista del meccanismo spesso indeboliscono di fatto l'architettura dell'applicazione, se non viene compresa l'assunzione.

Gestione del progetto

  • Attività: Pianificazione dell'iterazione successiva

    Utilizzando i sottosistemi di implementazione come 'unità logiche di responsabilità', il lavoro di costruzione può essere suddiviso in due o più "tracce" parallele: una che si occupa della funzionalità specifica per applicazione e le altre (una o più) che si occupano dei componenti generici riutilizzabili. Questo naturalmente dipende da una sufficiente disponibilità di risorse da assegnare ai paralleli impegni lavorativi relativi allo sviluppo. La capacità di suddividere i team di sviluppo e di lavorare in parallelo dipende interamente dalla stabilità dell'architettura e, più nello specifico, dalla qualità e dalla stabilità delle interfacce fra i componenti. Un valido impegno durante la fase di elaborazione consentirà questa suddivisione.

Attività della fase di costruzione

Alla fase di costruzione viene applicato il flusso di lavoro di base, con le seguenti estensioni o variazioni:

Gestione del progetto

  • Attività: Pianificazione dell'iterazione successiva

    La pianificazione della prima iterazione della costruzione è stata trattata in precedenza, poiché ricorre al termine della fase di elaborazione. La pianificazione delle successive iterazioni e la possibilità di suddividere il team di sviluppo e lavorare in parallelo continua a dipendere dalla stabilità dell'architettura e dalla qualità e stabilità delle interfacce fra i componenti.

Analisi e progettazione

  • Attività: Perfezionamento dell'architettura e Attività: Progettazione dei componenti

    Il punto focale della costruzione è l'analisi della parte restante dei casi d'uso e l'identificazione dei componenti e delle collaborazioni di componenti appropriati che realizzano i casi d'uso. L'architettura esistente viene espansa e completata, ed i 'comportamenti interni' del componente vengono completamente progettati ed implementati.

  • Attività: Progettazione del database

    Il punto focale della costruzione è completare la progettazione del database, verificando che tutte le classi persistenti siano supportate sia dal database che dal meccanismo di persistenza. Questo lavoro viene eseguito in parallelo e in modo iterativo con il lavoro svolto in Attività: Perfezionamento dell'architettura e Attività: Progettazione dei componenti. L'organizzazione ideale è di disporre di team integrati di componenti, con il coordinamento fra i team sulle problematiche relative alla persistenza, per garantire una buona progettazione del database.

Implementazione

Test

La verifica delle prestazioni resta importante ma è presente una maggiore attenzione per i test funzionali. E' necessario occuparsi anche della completezza della funzionalità, della verifica di regresso della funzionalità esistente e della conformità con le aspettative di prestazione.

Attività della fase di transizione

  • Il rilascio del prodotto in ambiente web tende ad essere incrementale e continuo, meno incentrato sulla tradizionale distribuzione dei supporti. La pianificazione dei rilasci deve essere effettuata di conseguenza.
  • Il supporto di produzione è sempre più il punto focale di questa fase.
  • Vengono eseguite le attività di conversione dati.