Linea guida: Rilevamento, analisi e controllo strutturale
Questa linea guida descrive il modo in cui eseguire il rilevamento, l'analisi e il controllo strutturale mediante l'ambiente di modellazione RSA per un progetto.
Relazioni
Elementi correlati
Descrizione principale

Introduzione

In diverse attività di RUP, viene presa in considerazione la necessità di esaminare il Modello di progettazione emergente, di valutare i diversi aspetti relativi alla qualità e, se necessario, di eseguire il refactoring del modello. È inoltre importante poter mantenere l'integrità strutturale di un sistema una volta che è stato spostato in un'implementazione, per assicurare che i vincoli di progettazione e strutturali non vengano violati e che il sistema, così come implementato, continui a essere in linea con la visione strutturale. In RUP, questi punti di controllo principali si verificano nei Compiti: analisi dell'architettura, analisi_della_progettazione_gui e revisione codice.

Un problema diverso, ma collegato, sorge durante le sintesi di progettazione e strutturali. Nei Compiti: Analisi strutturale (vedere Sviluppo della panoramica strutturale e Valutazione delle risorse disponibili) e Inclusione di elementi di progettazione esistenti, si consiglia all'Architetto software di cercare opportunità di riutilizzo delle risorse di codice e di progettazione esistenti, includendole nel modello di progettazione dopo il reverse engineering, se necessario. Se le risorse riutilizzate non vengono fornite con un determinato tipo di certificazione della qualità, l'Architetto software desidererà sottoporle allo stesso esame della progettazione e del codice appena creati.

In entrambi i casi, le esigenze conseguenti dell'Architetto software saranno le stesse per questa analisi statica:

  • Prendere un'applicazione codificata (o un frammento di questa), rilevarne la struttura simbolica e recuperarla, idealmente in un modello di progettazione in forma UML. Il recupero di artefatti documentari esplorabili presenta anche il significativo vantaggio di consentire all'Architetto software di esaminare il modo in cui è strutturato effettivamente il codice, quando la documentazione non esiste o è obsoleta
  • Poter analizzare qualsiasi modello di progettazione, raccogliere la metrica per la qualità (quale  Definizione del termine: accoppiamento) richiamata nell'Artefatto: Piano di misurazione e verificare la conformità con l'Artefatto: Documento dell'architettura software e le Linee guida di progettazione
  • Essere informato delle modifiche significative a livello di progettazione o strutturale in modo che possa essere compiuta un'azione correttiva, se necessario. L'importanza di tali modifiche viene valutata in base ai criteri impostati dall'Architetto software

In teoria, queste esigenze potrebbero essere soddisfatte tramite l'ispezione; in pratica, per sistemi più grandi e complessi, è fondamentale un certo tipo di assistenza automatizzata. Nelle sezioni seguenti vengono forniti un'elaborazione di questi argomenti ed esempi di supporto di tool.

Rilevamento e recupero dell'architettura

Premessa

Nello sviluppo Greenfield, l'architettura software emerge dai requisiti e dalle convenzioni nonché dal contesto del dominio (inclusi i pattern e i meccanismi); l'artefatto Specifiche supplementari svolge un ruolo importante nella determinazione dell'architettura. Questo processo di modellazione dell'architettura software è talora denominato rilevamento, poiché vi è raramente una mappatura meccanica diretta dai requisiti all'architettura. Qui, tuttavia, rilevamento viene utilizzato in un altro senso, ossia per descrivere il processo di supporto all'Architetto software nella comprensione di un'applicazione esistente o di un suo frammento in forma codificata. Il recupero strutturale è più ambizioso: attraverso questo, infatti, non solo l'Architetto software cerca di comprendere un'applicazione ma estrae anche un modello di tale applicazione, idealmente a un livello di astrazione compatibile con il modello di progettazione. Esiste quindi la possibilità di unire questi modelli e, attraverso la Definizione del termine: trasformazione, di generare una nuova applicazione, forse per una Definizione del termine: piattaforma diversa.

Rilevamento

Nei Compiti: Analisi strutturale (vedere Sviluppo della panoramica strutturale e Valutazione delle risorse disponibili) e Inclusione di elementi di progettazione esistenti, l'Architetto software cerca opportunità per riutilizzare le risorse esistenti di progettazione e di codice. Ad esempio, un'organizzazione potrebbe disporre di diverse Architetture di riferimento nella propria base di risorse e idealmente queste sono complete di modelli e documentazione aggiornata. Di frequente, tuttavia, è disponibile poco più del codice sorgente e, se esiste una documentazione strutturale, non è attuale.

In molti casi l'Architetto software non può trattare tale codice come scatola nera (anche se le interfacce sono definite in modo chiaro), ma deve comprenderne la struttura. Questo processo è notevolmente supportato dalla possibilità di generare automaticamente descrizioni esplorabili del codice. L'Architetto software può quindi "rilevare" visivamente pattern e anti-pattern nel codice. Un esempio di questo tipo di assistenza è reperibile nel tool Rational Software Architect, in cui la funzionalità di rilevamento dell'architettura popolerà automaticamente i diagrammi degli argomenti, quali la struttura del pacchetto, gli elementi interni della classe, le strutture ad albero dell'ereditarietà e le collaborazioni, per le applicazioni Java. Per ulteriori informazioni, vedere icona della guida la documentazione relativa a Rational Software Architect.

Recupero e trasformazione

Quando le risorse riutilizzabili sono complete di modelli, è possibile combinare tali modelli con modelli specifici del progetto e quindi procedere nell'implementazione specifica della piattaforma mediante le tecniche di trasformazione. Quando esiste solo il codice, potrebbe essere sempre possibile riutilizzarlo anche con un approccio basato sulla trasformazione, integrando il codice prodotto dalla trasformazione con quello preesistente.

L'Architetto software dispone di maggiore potere e flessibilità attraverso l'utilizzo del recupero dell'architettura: la funzionalità di recupero, infatti, genererà un modello dell'applicazione completo a livello semantico che può essere utilizzato per la generazione di codice e per l'esplorazione. In pratica, effettuare il reverse engineering del codice a una rappresentazione visiva diretta è spesso possibile; mentre astrarre tale modello allo stesso livello di un modello di progettazione Definizione del termine: modello indipendente dalla piattaforma è, in generale, difficile da automatizzare completamente.

Si tratta essenzialmente di una trasformazione da Definizione del termine: modello specifico della piattaforma a Definizione del termine: modello indipendente dalla piattaforma (vedere Concetto: MDD (Model Driven Development) e MDA (Model Driven Architecture)); il PIM (frammento) recuperato viene quindi combinato con il modello di progettazione (a sua volta un PIM) mediante un tipo di trasformazione di unione di modelli (vedere [OMG03]).

Analisi delle architetture

La disponibilità di modelli esplorabili consente all'Architetto software di verificare la qualità strutturale attraverso l'ispezione. Tuttavia, questa operazione può essere noiosa e dispendiosa in termini di tempo e controllare la conformità delle regole e degli standard nonché raccogliere la metrica in questo modo può generare errori. L'Architetto software deve cercare di automatizzare il più possibile questo processo e così dedicare più tempo all'individuazione e all'applicazione di rimedi; l'automazione gli consente di sperimentare, esaminare le varie ipotesi e controllare rapidamente il risultato.

Elementi suscettibili di automazione

L'analisi strutturale automatizzata può:

  • Individuare pattern e anti-pattern (strutture patologiche) nell'architettura
  • Eseguire misurazioni su diverse strutture e Metriche di report
  • Controllare la conformità con i vincoli dell'Architetto software (vedere Controllo strutturale)

Il Definizione del termine: pattern è dettato dagli standard dell'organizzazione e del progetto e il fondamento logico per il relativo utilizzo viene acquisito nel Documento dell'architettura software (se presentano importanza strutturale) o nelle Linee guida di progettazione. Tramite l'analisi automatizzata, l'Architetto software può controllare rapidamente l'utilizzo dei pattern per verificare che gli scopi del Documento dell'architettura software e delle Linee guida di progettazione siano stati raggiunti. Gli anti-pattern sono strutture di progettazione e strutturali patologiche che in qualche modo indeboliscono l'architettura, rendendola ad esempio meno robusta, più complessa o più difficile da gestire.

Le misurazioni da eseguire vengono definite in Prodotto di lavoro: Piano di misurazione (alcune metriche consigliate sono reperibili in Linea guida: Metriche). Il Piano di misurazione descrive inoltre il modo in cui una metrica deve essere utilizzata, ad esempio se sono migliori valori superiori o inferiori o se è il trend che è importante. Pertanto è utile che l'analisi delle metriche identifichi anche aree sensibili/posizioni nell'architettura, in cui una modifica genererebbe un notevole miglioramento nelle metriche raccolte. Non sorprende, dunque, che queste vengano spesso associate a patologie nella struttura. L'Architetto software ha quindi una base oggettiva per apportare il miglioramento, può effettuare modifiche o delegare le azioni successive, verificabili una volta completate.

Definizione dello scopo dell'analisi

Lo scopo dell'analisi può variare nel ciclo di vita, a seconda dell'approccio di sviluppo scelto. Quando un progetto utilizza un approccio trasformazionale (generazionale), lo scopo sarà normalmente il modello di progettazione, sul presupposto che l'applicazione generata sia sempre sincronizzata con la progettazione. Quando viene creato un Artefatto: Modello di implementazione e viene gestito separatamente oppure quando il codice viene riutilizzato, l'attenzione si sposta sul codice per assicurare che conservi l'integrità strutturale quando misurato in base al Documento dell'architettura software e alle Linee guida di progettazione.

Questo tipo di analisi (su un modello di implementazione) potrebbe non recuperare effettivamente un modello di progettazione esplicito dal codice, ai fini dell'analisi; è, nondimeno, relativo ai problemi di architettura e progettazione (quando sono evidenti nel codice) e non agli standard di codifica.

Esempio di questi concetti e funzionalità

Lo strumento Rational Software Architect, oltre alla possibilità di recuperare la documentazione relativa alle applicazioni Java attraverso il rilevamento dell'architettura, può identificare e creare report in base a un insieme di pattern predefiniti che potrebbero indicare potenziali "punti caldi" dell'architettura. Questi pattern includono, tra gli altri:

  • Butterfly
  • Breakable
  • Hub
  • Tangle
Butterfly

Un butterfly è un elemento, quale una classe, che presenta diverse relazioni con altri elementi dipendenti che verrebbero influenzati se butterfly fosse modificato. Se le relazioni sono dirette, questi elementi verranno denominati butterfly locali. Rational Software Architect può anche tenere traccia delle relazioni poiché si snodano lungo un'applicazione e determinano se le modifiche a un elemento possono interessare non solo gli elementi direttamente dipendenti, ma anche quelli dipendenti a loro volta da questi e così via per proprietà transitiva nell'intera applicazione. Tale elemento con diverse dipendenze indirette viene denominato butterfly globale. Di seguito viene mostrata un'illustrazione di un butterfly locale. Il diagramma mostra anche che le relazioni possono essere diverse dalle dipendenze UML: ad esempio, un elemento è dipendente da un altro quando lo realizza; una modifica nell'elemento di specificazione interesserà, pertanto, l'elemento che lo realizza.

Classe con quattro elementi dipendenti, due con dipendenze d'uso, uno con una relazione di generalizzazione e uno con una relazione di realizzazione

Butterfly locale

Breakable

Un breakable è un elemento che presenta diverse dipendenze, ossia ha diverse relazioni in cui dipende da un altro elemento. Una modifica a uno di questi altri elementi interesserà anche un breakable. Come con i butterfly, quando le relazioni sono dirette, questi elementi verranno denominati breakable locali e breakable globali se esistono molte relazioni indirette che hanno impatto sull'elemento. Un breakable globale è vulnerabile alle modifiche in molte parti di un'applicazione e indica una mancanza di modularità. Di seguito viene mostrata un'illustrazione di un breakable locale.

Classe con quattro elementi dipendenti, due in base a relazioni di dipendenza d'uso, uno in base a una relazione di generalizzazione e uno in base a una relazione di realizzazione.

Breakable locale

Hub

Un hub è un elemento che combina le caratteristiche di un butterfly e di un breakable. Anch'esso presenta le forme locale e globale. La presenza di hub globali è un'indicazione di scarso partizionamento, che determina un software estremamente sensibile alle modifiche (che tendono a propagarsi nell'intera applicazione).

Tangle

Un tangle rappresenta un grande gruppo di elementi, le cui relazioni sono così complicate che una modifica in uno qualsiasi di essi può interessare tutti gli altri. Tali strutture sono una fonte di grande instabilità.

L'Architetto software, utilizzando il tool Rational Software Architect, può rilevare queste aree sensibili rapidamente e collaborare con il Progettista per correggerle. Per ulteriori informazioni, vedere icona della guida la documentazione relativa a Rational Software Architect.

Tempistica

I risultati di queste analisi sono preziosi in qualsiasi punto cardine della revisione, come prova oggettiva e quantificabile della qualità di progettazione e strutturale, oppure quando, come in Aggiornamento dell'organizzazione del modello di progettazione (in Compito: Inclusione di elementi di progettazione esistenti), esistono significative modifiche strutturali.

Controllo strutturale

La visione dell'Architetto software viene acquisita nel Documento dell'architettura software e la guida pratica relativa al Progettista è disponibile nelle Linee guida di progettazione. Anche quando tale visione viene condivisa da tutto il personale, talora viene offuscata dalle esigenze giornaliere del lavoro del progetto. Con le scadenze da rispettare, infatti, potrebbero essere aggirate le regole e d'altra parte l'Architetto software di solito non può partecipare a tutte le decisioni. Pertanto sorge il problema del controllo: così come il Responsabile di progetto deve impostare soglie e limiti e monitorarli (vedere Compito: Controllo stato del progetto), l'Architetto software ha un'attività analoga relativa all'implementazione e progettazione di software emergente.

Il controllo strutturale offre all'Architetto software la possibilità di creare regole per rafforzare i vincoli strutturali. Ad esempio, l'Architetto software potrebbe definire una regola che genererebbe un avviso a ogni realizzazione di una particolare interfaccia. La semplice espressione di questa regola senza supporto di tool richiederebbe una revisione più o meno costante per individuare le violazioni. Con l'automazione, le regole possono essere codificate in modo che le violazioni dell'insieme di regole possano essere individuate durante l'analisi dell'architettura. Tale evenienza si verifica sempre a fatto compiuto e un ambiente di controllo avanzato codificherebbe le regole nel processo di produzione del codice e della progettazione, impedendo in primo luogo che siano violate; in ogni caso, viene migliorato notevolmente il processo di revisione manuale.

Il tool Rational Software Architect include tale funzionalità per le applicazioni Java: l'Architetto software può impostare regole ed eseguire analisi per verificare la conformità. Per ulteriori informazioni, vedere icona della guida la documentazione relativa a Rational Software Architect.