Architettura logica e gli strati - Start point

L'architettura logica di un sistema software è l'organizzazione su larga scala delle classi software in package, sottoinsiemi e strati. L'architettura di un sistema software può essere organizzata secondo diversi "stili". Uno stile comune per l'architettura logica è l'architettura a strati, in cui il sistema è formato da un insieme di elementi chiamati strati. Ciascuno strato è un gruppo a grana molto grossa di classi, package o sottoinsiemi, che ha delle responsabilità coese rispetto a un aspetto importante del sistema.

Gli strati più alti ricorrono ai servizi degli strati più bassi. In genere non avviene il contrario.
Normalmente gli strati sono:

  • User interface, si tratta di oggetti per gestire l'interazione con l'utente;
  • Application Logic e Domain Objects, oggetti software che rappresentano concetti del dominio;
  • Technical Services, oggetti e sottoinsiemi d'uso generale che forniscono servizi tecnici di supporto: accesso alla basa di dati, logging degli errori, ecc.

In un'architettura a strati stretta, uno strato può richiamare i servizi dello strato immediatamente sottostante. Questa struttura è comune nei protocolli di rete organizzati a pila. Nell'ambito del software l'architettura a strati è più flessibile.

Mantenere una separazione degli interessi
...

In uno strato, le responsabilità degli oggetti devono essere fortemente correlate l'uno all'altro, e non devono essere mischiate con le responsabilità degli altri strati. Per esempio, gli oggetti dello strato UI devono essere incentrati sulle attività dell'interfaccia utente (catturare eventi del mouse, della tastiera, ...). Gli oggetti dello strato della logica applicativa o del dominio devono essere incentrati sulla logica applicativa (calcolare il totale di una vendita o le imposte su di essa).

L'interfaccia utente non deve implementare logica applicativa.
Un oggetto Java Swing Frame non deve contenere logica per calcolare le imposte di una vendita.
D'altra canto, oggetti del dominio non devono svolgere compiti della UI, come catturare eventi emessi da mouse o tastiera. Ciò violerebbe i principi di una chiara separazione degli interessi.

Lo strato del dominio è parte del software, mentre il modello di dominio è parte dell'analisi da un punto di vista concettuale. Essi non sono la stessa cosa. Tuttavia, si può creare uno strato del dominio ispirandosi al modello di dominio, in tal modo si ottiene un salto rappresentazionale basso tra il dominio del mondo reale e il progetto software.

Principio di separazione Modello-Vista
...

  1. Gli oggetti non UI non devono essere connessi o accoppiati direttamente agli oggetti UI. Per esempio, non permettere a un oggetto software Sale di avere un riferimento a un oggetto finestra JFrame di Java Swing.
  2. Non mettere logica applicativa (come il calcolo delle imposte) nei metodi di un oggetto dell'interfaccia utente. Gli oggetti UI dovrebbero solo inizializzare gli elementi dell'interfaccia utente, ricevere eventi UI, e delegare le richieste di logica applicativa agli oggetti non UI.

Modello: sinonimo per lo strato di oggetti del dominio.
Vista: sinonimo per gli oggetti dell'interfaccia utente.

Gli oggetti del modello non devono avere una conoscenza diretta degli oggetti della vista.

Legame tra SSD, operazioni di sistema e strati
...

Durante il lavoro di analisi, sono stati abbozzati alcuni SSD per gli scenari dei casi d'uso. Sono stati identificati gli eventi di input nel sistema da parte di attori esterni, per richiedere l'esecuzione delle operazioni di sistema.

Gli SSD, mostrano queste operazioni di sistema, ma nascondono gli oggetti specifici della UI. Ciò nonostante, normalmente saranno gli oggetti dello strato UI del sistema a catturare queste richieste di operazioni di sistema, solitamente attraverso una UI grafica (GUI).

Gli oggetti dello strato UI inoltreranno le richieste da parte dello strato UI allo strato del dominio.

Il punto è il seguente

I messaggi inviati dallo strato UI allo strato del dominio saranno i messaggi mostrati negli SSD.