Architettura logica

Ponte di collegamento tra l'analisi e la progettazione:

L'architettura logica così ottenuta dovrebbe essere vista come la specifica di un insieme di vincoli (strutturali, comportamentali e di interazione) imposti dal problema e/o dal dominio applicativo che limitano di fatto lo spazio delle soluzioni.
In altre parole, se l'analisi del problema riesce ad identificare le forze rilevanti in gioco e a stabilire come esse interagiscono e confliggono tra loro, allora è possibile anche delineare i trade-offs che ne possono emergere e specificare i tratti salienti di una architettura logica in grado di fornire un limite alla creativtà inconcludente e costituire un buon punto di partenza per la risoluzione del problema stesso.
Tali vincoli devono essere individuati tenendo conto dei requisiti, dell'ambiente, e del contesto socio-economico in cui si inserisce l'applicazione, evitando di introdurre vincoli dettati da specifiche tecnologie realizzative (a meno che queste non siano esplicitamente menzioate nei requisiti).

L'architettura logica costituisce quindi un modello del sistema ispirato dai requisiti funzionali e dalle forze in gioco nel dominio applicativo o dalla specifica applicazione e mira ad identifica i macro sottosistemi in cui il sistema stesso suggerisce di articolare il sistema risolvente.

La definizione della architettura logica permette di promuovere lo sviluppo di una soluzione modulare e agevolare una pianificazione del lavoro adeguata ai vincoli temporali con cui produrre le diverse versioni del sistema.
L'architettura logica di un sistema costituisce un modello del sistema ispirato dai requisiti funzionali e dalle forze in gioco nel dominio applicativo o nella specifica applicazione e mira ad identificare i macro-sottosistemi logici che lo compongono e le parti legacy di cui occorra tenere conto.
L'architettura logica è quindi il più possibile indipendente da ogni ipotesi sull'ambiente di implementazione.

L'architettura logica mira a modellare non una soluzione al problema, ma il problema stesso.
Questa modellazione coinvolge tutte le dimansioni tipiche di un'architettura, rendendo esplicita la conoscenza della struttura, del comportamento e dell'interazione tra i vari componenti appartenenti al sistema analizzato.

Punti chiave

  1. E' l'insieme delle parti e delle interazioni che si evincono dall'analisi del problema, cioè dai vincoli imposti dal problema.
  2. Le linee base dell'architettura sono guidate da un insieme di casi d'uso critici (individuati nell'analisi del problema).
  3. La descrizione dell'architettura logica è una guida importantissima nell'intero processo di sviluppo.
  4. Robustezza: cambiamenti sui requisiti devono impattare solo su pochi casi d'uso (o pochi packages)

E' possibile partizionare gli use cases in oggetti di tre categorie, ottenute articolando lo spazio concettuale in tre dimensioni:

  • Informazioni: è la dimensione relativa alle entità del sistema cui corrisponde l'insieme degli oggetti che includono funzioalità relative alle informazioni che caratterizzano il sistema (questi oggetti son detti oggetti entità).
  • Presentazione: è la dimensione relativa alle funzionalità che dipendono dall'ambiente esterno cui corrisponde l'insieme degli oggetti che incapsulano l'interfaccia del sistema verso il mondo esterno (questi oggetti son detti oggetti oggetti interfaccia).
  • Controllo: è la dimensione relativa agli enti che incapsulano il controllo cui corrisponde l'insieme degli oggetti che includno le funzionalità non incapsulabili negli oggetti della categorie precedenti. Il loro compito, tipicamente, è di fare da collante tra gli oggetti interfaccia e gli oggetti entità (questi oggetti son detti oggetti controllo).

Ne consegue un approccio di analisi rappresentabile nel seguente modo:

che risulta quasi articolata in una sequenza di livelli (layer) verticali mantenuta anche in fase di progetto e realizzazione.

Tracciabilità

Specificare quali entità logiche realizzano un dato caso d'uso; nei diagrammi d'interazione sarà specificato come queste entità collaborano per realizzare un caso d'uso.

Analisi dei casi d'uso

  • Dalla specifica del caso d'uso, individuare le entità.
  • Per ogni caso d'uso, introdurre una control class per coordinare le altre classi nella realizzazione del caso d'uso.
  • Per ogni attore che interagisce col caso d'uso, definire una boundary.
  • Un sottoinsieme critico dei casi d'uso guida le linee base dell'architettura.