Operazione: Analisi strutturale
Questa attività concentra l'attenzione sulla definizione di un'architettura candidata e sulla determinazione delle tecniche strutturali da utilizzare nel sistema.
Scopo
  • Per definire un'architettura candidata al sistema basata sull'esperienza acquisita da sistemi o in domini di problemi simili.
  • Per definire i modelli strutturali, i meccanismi chiave e le convenzioni di modellazione.
Relazioni
Descrizione principale

L'analisi strutturale concentra l'attenzione sulla definizione di un'architettura candidata e sulla determinazione delle tecniche strutturali da utilizzare nel sistema. Si affida alla raccolta dell'esperienza acquisita in sistemi analoghi o domini del problema per vincolare e concentrare l'attenzione sull'architettura in modo da non sprecare l'impegno lavorativo nella riscoperta strutturale. Nei sistemi in cui esiste già un'architettura ben definita, l'analisi strutturale potrebbe essere omessa; l'analisi strutturale è fondamentale quando si sviluppano sistemi nuovi e senza precedenti.

Passi
Panoramica sullo sviluppo dell'architettura
Scopo  Per facilitare la concezione del sistema esaminando e valutando le opzioni strutturali di livello elevato. 
Per trasferire una prima conoscenza della struttura di livello elevato del sistema progettato ai finanziatori, ai team di sviluppo e ad altri portatori d'interesse.

E' necessario creare una panoramica dell'architettura in anticipo nel ciclo di vita di un progetto, possibilmente già nella fase iniziale. Ciò rispecchia le decisioni prese in anticipo ed i presupposti lavorativi sull'implementazione della Vista, oltre alle decisioni riguardanti l'architettura fisica e logica ed i requisiti non funzionali del sistema. La panoramica viene realizzata dall'architetto di software, spesso in collaborazione con il finanziatore del progetto, e assume l'aspetto di una grafica ad icona o di uno storyboard di immagini informale. Concettualmente, illustra la natura essenziale della soluzione proposta, trasferendo le idee determinanti e includendo i principali blocchi. Il livello di formalità della panoramica strutturale è dipendente dal progetto. Ad esempio, in un ampio progetto di elevata formalità, potrebbe essere necessario dover catturare il riepilogo strutturale nelle sezioni appropriate del documento Architetto software.

A questo punto la panoramica sull'architettura è un primo passaggio provvisorio. Non effettuare dei commitment nel diagramma di riepilogo dell'architettura finché il prototipo strutturale eseguibile non abbia convalidato l'architettura, compresi la progettazione, l'implementazione e la distribuzione.

Prendere in considerazione di basare l'architettura su una di riferimento, con altri pattern strutturali o altre risorse strutturali.

Verificare se si intende perfezionare e gestire il diagramma di riepilogo dell'architettura, per essere utilizzato come mezzo di comunicazione.

Molti sistemi sono vincolati allo sviluppo e alla distribuzione in un ambiente esistente di hardware e software; per tali sistemi, l'architetto di software raccoglierà le informazioni sull'ambiente corrente.

Ad esempio, in un ambiente di sviluppo del sistema di e-business le seguenti informazioni sono pertinenti:

  • progettazione fisica e logica di rete esistente
  • progettazione di database e database esistenti
  • ambiente Web esistente (server, firewall e così via)
  • ambiente server esistente (configurazione, versioni software e aggiornamenti pianificati)
  • standard esistenti (rete, denominazione, protocolli e così via)

Tali informazioni possono essere catturate sia testualmente che in un Modello di distribuzione.

Valutazione dei beni disponibili
Scopo  Per identificare i beni che potrebbero essere attinenti al progetto.
Per analizzare le corrispondenze e le differenze tra i beni ed i requisiti del progetto.
Per decidere se basare le aree di sistema sulle risorse.
Per individuare ed elencare i beni che possono essere potenzialmente riutilizzabili nel progetto.
Per eseguire una valutazione preliminare al fine di essere certi che il supporto richiesto sia potenzialmente disponibile.

E' necessario conoscere i requisiti dell'ambiente per cui vengono esaminate le risorse e l'ambito del sistema e la funzionalità generali richiesti. Effettuare una ricerca nelle risorse organizzative e nelle documentazioni industriali per individuare progetti simili. Esistono diversi tipi di beni da considerare, quali (ma non circoscritti ad essi) i modelli industriali, i framework, le classi e le esperienze. E' necessario valutare se i beni disponibili contribuiscono alla soluzione delle sfide principali del progetto corrente e se sono compatibili con i vincoli del progetto.

Sarà possibile analizzare il grado di adattabilità esistente tra le risorse ed i requisiti del cliente, per comprendere se qualche requisito è negoziabile (per attivare l'utilizzo della risorsa).

Occorre essere certi di valutare se la risorsa può essere modificata o estesa per poter soddisfare i requisiti e quali sono i compromessi in termini di costo, rischo e funzionalità nell'utilizzo della risorsa.

Infine, sarà possibile decidere, in principio, se utilizzare una o più risorse e documentare i presupposti logici per questa decisione.

Definizione dell'organizzazione di livello elevato dei sottosistemi
Scopo Per creare una struttura iniziale del modello di progettazione.

Quando si concentra l'attenzione sull'esecuzione della sintesi strutturale durante la fase iniziale, questa procedura è esclusa da questa attività.

Di solito il modello di progettazione è organizzato in strati, un pattern strutturale comune per migrare a sistemi più grandi. Il numero di livelli non è predeterminato, ma varia da condizione a condizione.

Durante l'analisi strutturale l'utente di solito concentra l'attenzione sui due livelli più elevati; cioè, i livelli applicazione e specifico del business. Ciò descrive il significato di organizzazione di elevato livello dei sottosistemi. Gli altri livelli più bassi sono discussi nella sezione Compito: Integrazione di elementi di progettazione esistenti. Se si utilizzano dei pattern strutturali specifici, i sottosistemi vengono definiti intorno alla maschera strutturale per quel pattern.

Per maggiori informazioni sulla strutturazione a livelli, consultare Linee guida per il prodotto di lavoro: Strutturazione a livelli.

Identificazione di astrazioni chiave
Scopo Per essere preparati all'analisi mediante identificazione delle astrazioni chiave (rappresentazione dei concetti identificati durante le attività di modellazione del business quando applicabile e dei requisiti) che il sistema deve gestire.

Quando l'attenzione è rivolta all'esecuzione della sintesi strutturale, questa fase viene eseguita fino al punto necessario per guidare l'architetto di software nella scelta delle risorse per la costruzione del Prodotto di lavoro: Proof-of-Concept (POC) strutturale e per supportare gli scenari di utilizzo del rappresentante.

Le attività dei requisiti e, quando applicabili, le attività di modellazione del business rilevano di solito i concetti chiave che il sistema deve essere in grado di gestire; questi concetti si manifestano come astrazioni di progettazione chiave. Dal momento che il lavoro è già stato eseguito, non occorre ripetere nuovamente il lavoro di identificazione durante Compito: Analisi del caso d'uso.

E' possibile trarre vantaggio delle attuali conoscenze identificando le classi di analisi entità preliminari per rappresentare queste astrazioni chiave sulla base delle nozioni generale del sistema, come i requisiti, il Glossario e, in particolare, il modello dominio o il Modello di analisi business (se disponibile).

Quando si definiscono le astrazioni chiave, definire anche tutte le relazioni che esistono tra le classi entità. Esporre le astrazioni chiave in uno o più diagrammi classe diversi e creare una breve descrizione per ciascuna. A seconda del dominio e della novità del sistema, i pattern di analisi che catturano molte delle astrazioni chiave richieste per modellare il sistema potrebbero già esistere. L'utilizzo di pattern di questo tipo (che dovrebbero già essere stati impiegati correttamente nel dominio) faciliterà considerevolmente l'onere intellettivo necessario per identificare gli importanti concetti che devono essere rappresentati. [FOW97a] propone alcuni pattern di analisi che sono direttamente utili ai sistemi business di modellazione, ma che potrebbero essere applicabili in altri contesti. Un altro esempio è l'OMG (Object Management Group), che tenta anche di definire le interfacce ed i protocolli per molti domini mediante il lavoro del proprio Comitato per la tecnologia del dominio e dei gruppi di attività associati. Inevitabilmente, questo lavoro conduce all'identificazione delle importanti astrazioni nel dominio.

A questo punto le classi di analisi identificate probabilmente cambieranno e si svilupperanno durante il corso del progetto. Lo scopo di questa fase è di non identificare una serie di classi che saranno disponibili durante tutta la progettazione, ma di identificare i concetti chiave che il sistema deve gestire. Evitare di impegnare molto tempo nel descrivere in dettaglio le classi entità in questa fase iniziale, poiché esiste il rischio che vengano identificate le classi e le relazioni non effettivamente richieste dai casi d'uso. Tenere presente che saranno individuate più classi entità e relazioni quando si controlleranno i casi d'uso.

Identificazione di interazioni stereotipate

Questa operazione viene inclusa solo quando viene eseguito questo compito nella fase d'inizio.

Lo scopo di questa operazione è di identificare queste interazioni, tra le astrazioni delle chiavi nel sistema, che caratterizzano o sono rappresentative di tipi di attività significativi nel sistema. Tali interazioni vengono catturate come Realizzazioni di casi d'uso.

Panoramica sullo sviluppo della distribuzione

Scopo

Per fornire una base che consente di valutare l'applicabilità di implementazione del sistema.
Per acquisire informazioni sulla distribuzione geografica e sulla complessità funzionale del sistema.
Per fornire una base per valutazioni anticipate sull'impegno e sui costi.

Sviluppare una panoramica di livello elevato su come viene distribuito il software. Ad esempio, stabilire se il sistema deve essere acceduto in remoto o se ha dei requisiti che suppongono la distribuzione su più nodi. Alcune fonti di informazioni da considerare sono:

  • utenti (nelle ubicazioni), definiti nei profili utente (nella visione) e casi d'uso (nel modello caso d'uso)
  • organizzazione dei dati business (quando disponibili, nel modello di progettazione e nel modello di analisi del business)
  • requisiti del livello di assistenza (nelle specifiche supplementari)
  • vincoli (nelle specifiche supplementari, come i requisiti per interfacciare con i sistemi legacy)

Se viene richiesto un sistema distribuito non superficiale, è quindi possibile utilizzare un modello di distribuzione per catturare la relazione tra i nodi. Ciò include in modo provvisorio l'assegnazione dei componenti e dei dati ai nodi e indica in che modo gli utenti accedono i componenti per l'accesso dei dati. Una specifica dettagliata dei nodi e delle connessioni viene rinviata, ad eccezione di quelle specifiche importanti per la valutazione o l'accertazione dell'applicabilità. E' possibile utilizzare delle risorse esistenti se disponibili. Sebbene questo sia il primo modello di distribuzione prodotto nel progetto e rapidamente di un livello elevato, esso potrebbe identificare gli effettivi prodotti hardware e software, se conosciuti, oppure se è importante effettuare adesso queste scelte.

Convalidare, nel modello di distribuzione, il supporto degli utenti (specialmente quelli in ubicazioni remote se è richiesto) che eseguono tipici casi d'uso mentre soddisfano requisiti e vincoli non funzionali. Convalidare l'idoneità dei nodi e delle connessioni a supportare le iterazioni tra i componenti su nodi diversi e tra i componenti e i relativi dati memorizzati.

Identificazione dei meccanismi di analisi
Scopo Per definire i meccanismi di analisi e servizi utilizzati dai progettisti per dare "vita" ai loro oggetti.

Quando si concentra l'attenzione sull'esecuzione della sintesi strutturale durante la fase iniziale, questa procedura è esclusa da questa attività.

I meccanismi di analisi possono essere identificati dall'alto verso il basso (conoscenza a priori) oppure dal basso verso l'alto (individuati mentre si procede). Nella modalità alto verso basso, la pratica guida l'architetto di software a riconoscere che certi problemi sono presenti nel dominio e che richiedono determinati tipi di soluzioni. Degli esempi di problemi strutturali comuni che potrebbero essere rivelati come meccanismi durante l'analisi sono: permanenza, gestione della transazione, gestione dell'errore, messaggistica e motori di deduzione. L'aspetto comune di tutti questi meccanismi è che ciascuno risulta una caratteristica generale di un'ampia classi di sottosistemi, fornendo una funzionalità che interagisce o supporta la funzionalità base dell'applicazione. I meccanismi di analisi supportano le caratteristiche richieste nei requisiti funzionali di base del sistema, indipendentemente dalla piattaforma su cui vengono distribuiti o il linguaggio di implementazione. I meccanismi di analisi possono anche essere progettati e implementati in diversi modi; in generale vi sarà più di uno meccanismo di progettazione corrispondente a ciascun meccanismo di analisi e probabilmente più di un modo per implementare ciascun meccanismo di progettazione.

La strategia "basso verso l'alto" è il punto in cui vengono definitivamente creati i meccanismi di analisi; vengono creati su indicazioni fornite dall'architetto di software, probabilmente con pochi elementi in principio, ma tuttavia con un tema comune che emerge da una serie di soluzioni richieste per diversi problemi. Vi è la necessità di fornire un modo per sincronizzare i clock degli elementi nei diversi thread e di fornire una modalità comune per assegnare le risorse. I meccanismi di analisi, che semplificano il linguaggio dell'analisi, emergono da questi schemi.

L'identificazione di un meccanismo di analisi significa che è stata individuata l'esistenza di un problema secondario comune e probabilmente implicito (in qui sono implicati i requisiti del sistema) e a cui viene fornito un nome. Inizialmente il nome può essere tutto ciò che esiste; ad esempio l'architetto di software riconosce che il sistema richiederà un meccanismo di permanenza. Infine, questo meccanismo sarà implementato attraverso la collaborazione di una società di classi (consultare [BOO98]), alcune delle quali non producono direttamente la funzionalità dell'applicazione, ma sono presenti per supportarla.Molto spesso queste classi di supporto sono presenti nei livelli intermedi o inferiori dell'architettura a livelli, pertanto fornendo un servizio di supporto comune per tutte le classi di livello dell'applicazione.

Se il problema secondario identificato è abbastanza comune, probabilmente esiste uno schema da cui è possibile avviare il meccanismo, collegando le classi esistenti e implementando quelle nuove come lo schema richiede. Un meccanismo di analisi prodotto in questo modo sarà astratto e richiederà un ulteriore perfezionamento attraverso la progettazione e l'implementazione.

Per maggiori informazioni, consultare Concetto: Meccanismi di analisi.

Revisione dei risultati
Scopo Per accertarsi che i risultati dell'analisi strutturale siano completi e coerenti.

Quando si conclude l'analisi strutturale, revisionare i meccanismi strutturali, i sottosistemi, le classi e i pacchetti che sono stati identificati per essere certi della loro completezza e coerenza. Così come i risultati dell'analisi strutturali sono provvisori e relativamente ufficiosi, anche le revisioni non devono essere ufficiali. Gli scenari o i casi d'uso possono essere utilizzati per convalidare le scelte strutturali effettuate a diversi livelli - dalla prospettiva di business verso il basso fino alle specifiche iterazioni che si verifichino.

Consultare Elenco di controllo: Documento dell'architettura del software - Considerazioni sull'analisi strutturale per maggiori informazioni sulla valutazione dei risultati di questa attività.



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