Operazione: Incorporo elementi di progettazione esistenti
Questa sezione illustra come far evolvere e perfezionare il modello di progettazione.
Scopo
  • Analisi delle iterazioni delle classi di analisi per identificare interfacce, classi di progettazione e sottosistemi di progettazione
  • Perfezionamento dell'architettura, considerando il riutilizzo dove possibile.
  • Identificazione di soluzioni comuni a problemi di progettazione incontrati di comune
  • Inserimento di elementi del modello di progettazione strutturalmente significativi nella sezione vista logica del documento dell'architettura software.
Relazioni
RuoliPrincipale: Aggiuntivo: Assistenza:
InputObbligatorio: Facoltativo:
  • Nessuno
Esterno:
  • Nessuno
Output
Passi
Identificazione delle possibilità di riutilizzo
Scopo Identificare la presenza di sottosistemi e/o componenti da poter riutilizzare sulla base delle loro interfacce.  

Ricerca di sottosistemi o componenti con interfacce simili. Confrontare ciascuna interfaccia identificata con quella presente in sottosistemi o componenti esistenti. Solitamente non si otterrà un'esatta corrispondenza, ma si potranno trovare delle similitudini. Andare alla ricerca di comportamenti e valori restituiti simili, e poi prendere in considerazione i parametri.

Modifica delle interfacce identificate per migliorarne l'adattamento. Vi potrà essere la possibilità di modificare minimamente l'interfaccia che si intende utilizzare in modo da migliorarne la congruenza con quelle esistenti. Le minime modifiche comprendono la riorganizzazione o l'aggiunta di parametri, e quindi la fattorizzazione tramite la separazione in diverse interfacce, una o più delle quali corrisponda a quelle del componente esistente, inserendo i "nuovi" comportamenti in interfacce separate.

Sostituzione delle interfacce candidate con quelle esistenti che presentano delle esatte corrispondenze. Dopo la semplificazione e la fattorizzazione, se vi è un'esatta corrispondenza in un interfaccia esistente, eliminare l'interfaccia candidata sostituendola con quella esistente.

Associazione del sottosistema candidato ai componenti esistenti. Identificare i componenti esistenti e l'insieme dei sottosistemi candidati. Fattorizzare il sottosistema in modo da utilizzare i componenti esistenti dove possibile per soddisfare i comportamenti richiesti del sistema. Dove è possibile realizzare un sottosistema candidato partendo da un componente esistente, creare una tracciabilità tra il sottosistema di progettazione ed il componente nel modello di implementazione.

Nell'associazione dei sottosistemi ai componenti riutilizzabili, considerare il meccanismo di progettazione associato al sottosistema; le prestazioni o i requisiti di sicurezza possono rendere un componente non sostituibile per quanto esso presenti delle esatte corrispondenze per altri aspetti.

Reverse-Engineer dei componenti e del database
Scopo Incorporazione di elementi del modello potenzialmente riutilizzabili da altri progetti, sorgenti esterne o precedenti iterazioni.  

Per completare il lavoro è possibile recuperare codice e definizioni di database provenienti da progetti o iterazioni precedenti e renderle disponibili a quelli attuali. Sfruttando le potenziali opportunità di riutilizzo come filtro, il lavoro di reverse engineering potrà concentrarsi unicamente sui componenti riutilizzabili per l'iterazione corrente.

Esecuzione del Reverse Engineer dei componenti

Nelle organizzazioni che creano sistemi simili, vi è spesso un insieme di componenti comuni che fornisce diversi meccanismi strutturali necessari al nuovo sistema. Potranno esserci anche componenti disponibili sul mercato che forniscono il meccanismo strutturale necessario. I componenti esistenti devono essere esaminati per determinarne la compatibilità ed adattabilità all'architettura software.

I componenti esistenti, sviluppati in iterazioni precedenti ma non ancora inclusi nel modello di progettazione, oppure i componenti acquistati, devono essere sottoposti a reverse-engineering ed incorporati nel modello di progettazione. Nei modelli di progettazione tali componenti sono comunemente rappresentati come un sottosistema con uno o più interfacce.

Esecuzione del Reverse Engineer dei database

I database, ed i dati in essi presenti, rappresentano una delle fonti più importanti di risorse riutilizzabili. Per riutilizzare le classi implicite incorporate in database esistenti, determinare quali delle informazioni utilizzate dall'applicazione siano già presenti. Eseguire il reverse-engineering di un insieme di classi per rappresentare la struttura del database che contiene l'informazione. Allo stesso tempo, costruire un'associazione tra la rappresentazione delle classi dell'applicazione e le strutture utilizzate nel database. Per ulteriori informazioni sul reverse engineering dei database, consultare Guida del prodotto di lavoro: Reverse-engineering di database relazionali. Per ulteriori informazioni sull'associazione delle classi e tabelle nei database relazionali, consultare Linee guida del prodotto di lavoro: Modello dei dati.

Aggiornamento dell'organizzazione del modello di progettazione
Scopo Considerazione dei nuovi elementi del modello nell'organizzazione del modello di progettazione.
Nuovo bilanciamento della struttura del modello di progettazione dove necessario. 

Aggiungendo nuovi elementi al modello di progettazione si rende spesso necessario un suo reimpacchettamento. Si ottengono così diversi risultati: riduzione delle dipendenze tra pacchetti ed il miglioramento della loro coesione nel modello di progettazione. L'intento principale e quello di consentire a pacchetti (e sottosistemi) diversi di essere progettati in modo indipendente l'uno dall'altro, da persone diverse del team. Mentre la completa indipendenza è praticamente impossibile da raggiungere, la diminuzione delle dipendenze tra i pacchetti tende semplificare lo sviluppo di sistemi grandi e complessi.

Un struttura di modello 'piatta' (dove tutti i pacchetti ed i sottosistemi si trovano allo stesso livello concettuale nel sistema) è adatta a piccoli sistemi; in sistemi più grandi si necessita di un ulteriore strutturazione definita 'strutturazione a livelli' (consultare Linee guida del prodotto di lavoro: Strutturazione a livelli). Le regole di strutturazione a livelli definiscono le restrizioni presenti sulle relazioni consentite tra determinati pacchetti. Tali regole riconoscono che determinate dipendenze non devono esistere: la funzionalità dell'applicazione non deve dipendere in modo diretto dal sistema operativo o dai servizi del sistema di finestre, dove esserci un livello intermedio contenente servizi di finestre e del sistema operativo logici che isoli la funzionalità dell'applicazione dalle modifiche nel servizi di implementazione di basso livello. La strutturazione a livelli consente di ridurre l'impatto delle modifiche: l'inserimento di regole che restringono le dipendenze tra i pacchetti ed i sottosistemi rende il sistema più solido. Gli si consente di sopportare le modifiche.

L'aggiunta di nuovi elementi del modello al sistema potrebbe rendere i pacchetti esistenti troppo grandi per essere gestiti da un unico team: si deve quindi dividerlo in più pacchetti con un'alta coesione interna, ma con basse dipendenze tra i pacchetti. quest'operazione potrebbe essere complicata, alcuni elementi potrebbero essere difficili da posizionare in un determinato pacchetto poiché essi potrebbero essere utilizzati da elementi di diversi pacchetti. Esistono due diverse soluzioni: dividere l'elemento in diversi oggetti, uno in ciascun pacchetto (questo è possibile in elementi che abbiano diverse 'personalità', o in insiemi con responsabilità in qualche modo disgiunte), oppure spostare l'elemento in un pacchetto di un livello sottostante, da cui tutti gli elementi di livello più alto dipendano in modo uguale.

Quanto più aumenta la complessità del sistema tanti più livelli saranno necessari per ottenere una struttura comprensibile e gestibile. Tuttavia sarà difficile avere strutture con più di 7-10 livelli, anche nei sistemi più grandi, poiché la complessità aumenta e diminuisce in proporzione al numero di livelli.

Di seguito viene mostrata un esempio di strutturazione a livelli che comprende livelli middleware e di software del sistema:

Diagramma di layout per un applicazione Java/Web

La strutturazione a livelli di un pacchetto di esempio di un'applicazione basata su Java/Web. Nota: le dipendenze dal pacchetto TCP/IP non verrebbero di solito modellate in modo esplicito, siccome l'utilizzo dei servizi TCP/IP è incapsulato in Java VM, java.rmi e nel browser web. Sono descritte solo per esempio.

Assegnazione delle responsabilità per i sottosistemi ed i livelli ai singoli o ai team. Ciascun pacchetto o sottosistema deve essere di responsabilità di una singola persona (se il suo ambito è piccolo) o di un team (se il suo ambito è più vasto).

Aggiornamento della vista logica

Quando determinate classi, pacchetti e sottosistemi (elementi del modello) sono importanti da un punto di vista strutturale, devono essere inclusi nella sezione Vista logica del prodotto di lavoro: Documento dell'architettura software. Si assicurerà in tal modo che i nuovi elementi del modello significativi per la struttura vengano comunicati agli altri membri del team del progetto.

In aggiunta coloro che hanno i ruoli di architetto di software e di tecnico del processo devono collaborare per fornire una guida dettagliata ai progettisti ed agli implementatori sull'utilizzo degli elementi di progettazione appena incorporati.



Proprietà
Ricorrenze multiple
Attivato da evento
In corso
Facoltativo
Pianificato
Ripetibile
Ulteriori informazioni