Operazione: Strutturazione del modello di implementazone
Questo compito definisce come stabilire la struttura degli elementi di implementazione sulla base delle responsabilità assegnate per il sottosistema di implementazione ed i suoi contenuti.
Relazioni
Passi
Definizione della struttura del modello di implementazione
Scopo Definizione della struttura del modello di implementazione. 

Avviare la fase di spostamento dello 'spazio di progettazione' nello 'spazio di implementazione' eseguendo il mirroring della struttura del modello di progettazione nel modello di implementazione.

I pacchetti di progettazione avranno dei sottosistemi di implementazione corrispondenti, che conterranno una o più directory e file (Artefatto: Elemento di implementazione) necessari all'implementazione degli elementi della progettazione corrispondenti. L'associazione del modello di progettazione al modello di implementazione potrebbe cambiare con l'assegnazione di ciascun sottosistema di implementazione ad un livello specifico dell'architettura.

Creare un diagramma per rappresentare la struttura del modello di implementazione (consultare Linee guida: Diagramma di implementazione).

Regolazione dei sottosistemi di implementazione
Scopo Adattare la struttura del modello in modo che rifletta l'organizzazione del team o i vincoli del linguaggio di implementazione.  

Decidere se è necessario modificare l'organizzazione del sottosistema, considerando dei piccoli problemi tattici relativi all'ambiente di implementazione. Di seguito sono riportati alcuni esempi di tali problemi tattici. Notare che se si decide di modificare l'organizzazione dei sottosistemi di implementazione si deve considerare anche se modificare il modello di progettazione oppure se mantenerlo diverso dal modello di implementazione.

  • Organizzazione del team di sviluppo. La struttura del sottosistema deve prevedere che diversi implementatori o team di implementatori procedano in parallelo senza troppe sovrapposizioni e confusione. Si consiglia di affidare la responsabilità di un sottosistema di implementazione ad un unico team. Ciò potrebbe significare la divisione in due di un sottosistema (se molto grande), e l'assegnazione dei due pezzi da implementare a due implementatori o team di implementatori diversi, in modo particolare se questi hanno cicli di build/rilascio differenti.
  • Dichiarazione dei tipi. Durante l'implementazione ci si potrebbe accorgere che un sottosistema deve importare dei prodotti di lavoro da un altro sottosistema, poiché è stato dichiarato un tipo in quel sottosistema. Solitamente ciò avviene quando si utilizzano linguaggi di programmazione a tipi, quali C++, Java e Ada. In questa situazione, ed in generale, è consigliabile estrarre le dichiarazioni dei tipi in sottosistemi separati.

Esempio

Si estraggono delle dichiarazioni di tipo dal Sottosistema D, in un nuovo sottosistema Types, per rendere il Sottosistema A indipendente dalle modifiche ai prodotti di lavoro pubblici (visibili) nel Sottosistema D.

Illustrazione dell'estrazione del sottosistema di dichiarazione dei tipi

Le dichiarazioni dei tipi sono estratte dal sottosistema D

.

  • Codice legacy e sistemi di componenti esistenti. Potrebbe essere necessario incorporare del codice legacy, una libreria di componenti riutilizzabili, o prodotti esterni. Se questi non sono stati modellati nel progetto sarà necessario l'aggiunta di sottosistemi di implementazione.
  • Regolazione delle dipendenze Supporre che un sottosistema A ed un sottosistema B hanno delle dipendenze di importazione tra loro. Tuttavia si vuole rendere B meno dipendente dalle modifiche nel sottosistema A. Estrarre i prodotti di lavoro di A, che B importa, ed inserirli in un nuovo sottosistema di implementazione A1 in un livello inferiore.

Diagramma di trasferimento a gruppi di un artefatto di esempio

I prodotti di lavoro sono estratti dal sottosistema A, ed inseriti nel sottosistema A1.

Adesso che il sottosistema di implementazione non ha più un'associazione diretta con i pacchetti/sottosistemi presenti nel modello di progettazione, si potrà effettuare la modifica corrispondente nel modello di progettazione (se si è deciso di mantenerlo in linea con il modello di implementazione), oppure tenere traccia della loro associazione (ad esempio tramite la tracciabilità o le dipendenze di realizzazione). Se e come avviene tale associazione è una decisione di processo che dovrà essere registrata nel Prodotto di lavoro: Linee guida specifiche del progetto.

Definizione delle importazioni di ciascun sottosistema di implementazione
Scopo Definire le dipendenze tra sottosistemi. 

Per ciascun sottosistema definire gli altri sottosistemi che importa. Ciò potrà essere effettuato per un intero insieme di sottosistemi, consentendo a tutti i sottosistemi di un livello di importare quelli del livello inferiore. Generalmente le dipendenze del modello di implementazione rifletteranno quelle del modello di progettazione, tranne che per quelle strutture in cui il modello di implementazione è stato regolato (consultare Regolazione dei sottosistemi di implementazione).

Presentare la struttura a livelli del sottosistema in diagrammi di componenti.

Gestione dei programmi eseguibili (e di altri oggetti derivati)

Gli eseguibili (e gli altri oggetti derivati) sono il risultato dell'applicazione di un processo di build ad un sottosistema di implementazione (sottosistemi) o di una sua parte, e così sono da essi logicamente dipendenti. Tuttavia, l'architetto di software, in collaborazione con il gestore della configurazione, dovrà decidere la struttura degli elementi di configurazione da applicare al modello di implementazione.  

Per semplificare la selezione ed i riferimenti, in particolar modo per la distribuzione, si consiglia di definire elementi di configurazione separati che contengano l'insieme dei programmi eseguibili distribuibili (quali programmi eseguibili vengono distribuiti, su quali nodi viene registrato il Modello di distribuzione). Quindi, nel caso più semplice, per ciascun sottosistema di implementazione vi sarà un elemento di configurazione per i programmi eseguibili da distribuire ed uno che contiene i sorgenti utilizzati per produrli.  Il sottosistema di implementazione può essere considerato come rappresentato da un elemento di configurazione composito contenente questi elementi di configurazione (ed forse altri, quali le risorse di test).

Dal punto di vista della modellazione, una raccolta di programmi eseguibili prodotta da un processo di build potrà essere rappresentata come un Prodotto di lavoro: Build (che è un pacchetto) contenuto nel sottosistema di implementazione associato (anch'esso un pacchetto).   

Gestione delle risorse di test
Scopo Aggiungere i prodotti di lavoro di test al modello di implementazione. 

In generale, i prodotti di lavoro dei test ed i sottosistemi di test in Rational Unified Process non vengono gestiti in modo molto diverso rispetto ad altri software sviluppati. Tuttavia, solitamente essi non fanno pare del sistema distribuito, e spesso non sono distribuibili al cliente. Perciò si consiglia di allineare le risorse di test con l'obiettivo del test (ad esempio elementi di implementazione per test di unità, sottosistema di implementazione per test di integrazione, sistema per test di sistema), ma di tenere le risorse di test, ad esempio, in directory di test separate, se il repository del progetto è organizzato come un insieme di gerarchie di directory. I sottosistemi di test distinti (destinati a test superiori al livello di test di unità) devono essere gestiti allo stesso modo degli altri sottosistemi di implementazione, come elementi di configurazione distinti.

Per la modellazione, una raccolta di prodotti di lavoro di test potrà essere rappresentata come un Prodotto di lavoro: Sottosistema di implementazione (un pacchetto). Per un test di unità, un tale sottosistema di test sarà solitamente contenuto nel sottosistema di implementazione associato (verificato). L'architetto di software, in collaborazione con il gestore della configurazione, dovrà decidere se, a questo livello, i prodotti di lavoro del test dovranno essere configurati insieme agli elementi di implementazione, o come elementi di configurazione separati. Per l'integrazione ed il test del sistema, il sottosistema di test potrà essere paritetico ad un sottosistema di implementazione in fase di test.

Aggiornamento della vista implementazione
Scopo Aggiornare la vista implementazione del documento dell'architettura software. 

La vista implementazione è descritta nel documento dell'architettura software. Questa sezione contiene i diagrammi dei componenti che mostrano i livelli, l'assegnazione dei sottosistemi di implementazione ai livelli, ed anche le dipendenze di importazione tra sottosistemi.

Valutazione del modello di implementazione
Proprietà
Ricorrenze multiple
Attivato da evento
In corso
Facoltativo
Pianificato
Ripetibile
Ulteriori informazioni