OOAD – Object Oriented Design

Dopo la fase di analisi, il modello concettuale è sviluppato ulteriormente in un modello orientato agli oggetti usando il design orientato agli oggetti (OOD). In OOD, i concetti indipendenti dalla tecnologia nel modello di analisi sono mappati in classi di implementazione, i vincoli sono identificati e le interfacce sono progettate, risultando in un modello per il dominio della soluzione. In poche parole, viene costruita una descrizione dettagliata che specifica come il sistema deve essere costruito su tecnologie concrete

Le fasi del design orientato agli oggetti possono essere identificate come –

• Definizione del contesto del sistema
• Progettazione dell’architettura del sistema
• Identificazione degli oggetti nel sistema
• Costruzione di modelli di progettazione
• Specificazione delle interfacce degli oggetti

Progettazione del sistema

La progettazione di sistemi orientati agli oggettiLa progettazione di sistemi orientati agli oggetti implica la definizione del contesto di un sistema seguito dalla progettazione dell’architettura del sistema.

• Contesto – Il contesto di un sistema ha una parte statica e una dinamica. Il contesto statico del sistema è progettato usando un semplice diagramma a blocchi dell’intero sistema che è espanso in una gerarchia di sottosistemi. Il modello dei sottosistemi è rappresentato da pacchetti UML. Il contesto dinamico descrive come il sistema interagisce con il suo ambiente. E’ modellato usando i diagrammi dei casi d’uso.

• Architettura del sistema – L’architettura del sistema è progettata sulla base del contesto del sistema in accordo con i principi della progettazione architettonica così come la conoscenza del dominio. Tipicamente, un sistema è partizionato in strati e ogni strato è decomposto per formare i sottosistemi.

Decomposizione orientata agli oggetti

Decomposizione significa dividere un grande sistema complesso in una gerarchia di componenti più piccoli con minore complessità, sui principi del divide et impera. Ogni componente principale del sistema è chiamato sottosistema. La decomposizione orientata agli oggetti identifica i singoli oggetti autonomi in un sistema e la comunicazione tra questi oggetti.

I vantaggi della decomposizione sono –

• I singoli componenti sono di minore complessità, e quindi più comprensibili e gestibili.

• Permette la divisione della forza lavoro con competenze specializzate.

• Permette di sostituire o modificare i sottosistemi senza influenzare altri sottosistemi.

Identificare la concorrenza

La concorrenza permette a più di un oggetto di ricevere eventi nello stesso momento e a più di un’attività di essere eseguita contemporaneamente. La concorrenza viene identificata e rappresentata nel modello dinamico.

Per abilitare la concorrenza, ad ogni elemento concorrente viene assegnato un thread di controllo separato. Se la concorrenza è a livello di oggetto, allora a due oggetti concorrenti vengono assegnati due diversi thread di controllo. Se due operazioni di un singolo oggetto sono di natura concorrente, allora quell’oggetto viene diviso tra diversi thread.

La concorrenza è associata ai problemi di integrità dei dati, deadlock e starvation. Quindi una chiara strategia deve essere fatta ogni volta che è richiesta la concorrenza. Inoltre, la concorrenza deve essere identificata nella fase di progettazione stessa, e non può essere lasciata per la fase di implementazione.

Identificazione dei modelli

Nella progettazione di applicazioni, alcune soluzioni comunemente accettate sono adottate per alcune categorie di problemi. Questi sono i pattern di progettazione. Un pattern può essere definito come un insieme documentato di blocchi di costruzione che possono essere usati in certi tipi di problemi di sviluppo di applicazioni.

Alcuni design pattern comunemente usati sono –

• Façade pattern
• Model view separation pattern
• Observer pattern
• Modello vista controller pattern
• Publish subscribe pattern
• Proxy pattern

Controllo degli eventi

Durante la progettazione del sistema, gli eventi che possono verificarsi negli oggetti del sistema devono essere identificati e trattati in modo appropriato.

Un evento è una specificazione di un avvenimento significativo che ha una posizione nel tempo e nello spazio.

Ci sono quattro tipi di eventi che possono essere modellati, vale a dire –

• Evento Segnale – Un oggetto nominato lanciato da un oggetto e catturato da un altro oggetto.

• Evento di chiamata – Un evento sincrono che rappresenta l’invio di un’operazione.

• Evento tempo – Un evento che rappresenta il passaggio del tempo.

• Evento cambiamento – Un evento che rappresenta il cambiamento di stato.

Gestione delle condizioni limite

La fase di progettazione del sistema deve affrontare l’inizializzazione e la terminazione del sistema nel suo complesso e di ogni sottosistema. I diversi aspetti che sono documentati sono i seguenti –

• L’avvio del sistema, cioè la transizione del sistema dallo stato non inizializzato allo stato stazionario.

• La terminazione del sistema, cioè, la chiusura di tutti i thread in esecuzione, la pulizia delle risorse e i messaggi da inviare.

• La configurazione iniziale del sistema e la riconfigurazione del sistema quando necessario.

• La previsione di guasti o la terminazione indesiderata del sistema.

Le condizioni limite sono modellate usando casi d’uso limite.

Progettazione degli oggetti

Dopo che la gerarchia dei sottosistemi è stata sviluppata, gli oggetti nel sistema sono identificati e i loro dettagli sono progettati. Qui, il progettista dettaglia la strategia scelta durante la progettazione del sistema. L’enfasi si sposta dai concetti del dominio dell’applicazione ai concetti del computer. Gli oggetti identificati durante l’analisi sono incisi per l’implementazione con l’obiettivo di minimizzare il tempo di esecuzione, il consumo di memoria e il costo complessivo.

La progettazione degli oggetti include le seguenti fasi –

• Identificazione degli oggetti
• Rappresentazione degli oggetti, cioè, costruzione di modelli di design
• Classificazione di operazioni
• Design di algoritmi
• Design di relazioni
• Implementazione di controllo per interazioni esterne
• Pacchetto di classi e associazioni in moduli

Identificazione degli oggetti

Il primo passo del design degli oggetti è l’identificazione degli oggetti. Gli oggetti identificati nelle fasi di analisi orientata agli oggetti sono raggruppati in classi e raffinati in modo che siano adatti all’implementazione effettiva.

Le funzioni di questa fase sono –

• Identificare e raffinare le classi in ogni sottosistema o pacchetto

• Definire i collegamenti e le associazioni tra le classi

• Designare le associazioni gerarchiche tra le classi, cioè, la generalizzazione/specializzazione e le eredità

• Progettare le aggregazioni

Rappresentazione degli oggetti

Una volta identificate le classi, esse devono essere rappresentate usando tecniche di modellazione degli oggetti. Questa fase comporta essenzialmente la costruzione di diagrammi UML.

Ci sono due tipi di modelli di progettazione che devono essere prodotti –

• Modelli statici – Per descrivere la struttura statica di un sistema usando diagrammi di classe e diagrammi di oggetti.

• Modelli dinamici – Per descrivere la struttura dinamica di un sistema e mostrare l’interazione tra le classi usando diagrammi di interazione e diagrammi di state-chart.

Classificazione delle operazioni

In questo passo, le operazioni da eseguire sugli oggetti sono definite combinando i tre modelli sviluppati nella fase OOA, cioè, modello di oggetto, modello dinamico e modello funzionale. Un’operazione specifica cosa deve essere fatto e non come deve essere fatto.

Sono eseguiti i seguenti compiti riguardanti le operazioni –

• Si sviluppa il diagramma di transizione di stato di ogni oggetto del sistema.

• Si definiscono le operazioni per gli eventi ricevuti dagli oggetti.

• Si identificano i casi in cui un evento innesca altri eventi nello stesso o in diversi oggetti.

• Si identificano le sotto-operazioni all’interno delle azioni.

• Le azioni principali sono espanse in diagrammi di flusso dati.

Design di algoritmi

Le operazioni negli oggetti sono definite usando algoritmi. Un algoritmo è una procedura a tappe che risolve il problema stabilito in un’operazione. Gli algoritmi si concentrano su come deve essere fatto.

Ci può essere più di un algoritmo corrispondente a una data operazione. Una volta identificati gli algoritmi alternativi, viene selezionato l’algoritmo ottimale per il dominio del problema dato. Le metriche per la scelta dell’algoritmo ottimale sono –

• Complessità computazionale – La complessità determina l’efficienza di un algoritmo in termini di tempo di calcolo e requisiti di memoria.

• Flessibilità – La flessibilità determina se l’algoritmo scelto può essere implementato adeguatamente, senza perdita di adeguatezza in vari ambienti.

• Comprensibilità – Questo determina se l’algoritmo scelto è facile da capire e implementare.

Progettazione delle relazioni

La strategia per implementare le relazioni deve essere tracciata durante la fase di progettazione degli oggetti. Le principali relazioni che vengono affrontate comprendono le associazioni, le aggregazioni e le eredità.

Il progettista dovrebbe fare quanto segue riguardo alle associazioni –

• Identificare se un’associazione è unidirezionale o bidirezionale.

• Analizzare il percorso delle associazioni e aggiornarle se necessario.

• Implementare le associazioni come un oggetto distinto, in caso di relazioni molti-a-molti; o come un collegamento ad altri oggetti in caso di relazioni uno-a-uno o uno-a-molti.

Per quanto riguarda le eredità, il designer dovrebbe fare quanto segue –

• Adeguare le classi e le loro associazioni.

• Identificare le classi astratte.

• Fare in modo che i comportamenti siano condivisi quando necessario.

Implementazione del controllo

Il progettista di oggetti può incorporare raffinamenti nella strategia del modello di state-chart. Nella progettazione del sistema, viene fatta una strategia di base per realizzare il modello dinamico. Durante la progettazione dell’oggetto, questa strategia è opportunamente abbellita per un’implementazione appropriata.

Gli approcci per l’implementazione del modello dinamico sono –

• Rappresentare lo stato come una posizione all’interno di un programma – Questo è il tradizionale approccio guidato dalla procedura per cui la posizione del controllo definisce lo stato del programma. Una macchina a stati finiti può essere implementata come un programma. Una transizione forma una dichiarazione di input, il percorso di controllo principale forma la sequenza di istruzioni, i rami formano le condizioni, e i percorsi a ritroso formano i cicli o le iterazioni.

• State Machine Engine – Questo approccio rappresenta direttamente una macchina a stati attraverso una classe di state machine engine. Questa classe esegue la macchina a stati attraverso un insieme di transizioni e azioni fornite dall’applicazione.

• Controllo come task concorrenti – In questo approccio, un oggetto è implementato come un task nel linguaggio di programmazione o nel sistema operativo. Qui, un evento è implementato come una chiamata inter-task. Conserva la concorrenza intrinseca degli oggetti reali.

Confezionamento delle classi

In qualsiasi progetto di grandi dimensioni, è importante il partizionamento meticoloso di un’implementazione in moduli o pacchetti. Durante la progettazione degli oggetti, le classi e gli oggetti sono raggruppati in pacchetti per permettere a più gruppi di lavorare in modo cooperativo su un progetto.

I diversi aspetti del packaging sono –

• Nascondere le informazioni interne dalla vista esterna – Permette ad una classe di essere vista come una “scatola nera” e permette di cambiare l’implementazione della classe senza richiedere a nessun client della classe di modificare il codice.

• Coerenza degli elementi – Un elemento, come una classe, un’operazione o un modulo, è coerente se è organizzato su un piano coerente e tutte le sue parti sono intrinsecamente correlate in modo da servire un obiettivo comune.

• Costruzione di moduli fisici – Le seguenti linee guida aiutano nella costruzione di moduli fisici –

  • Le classi in un modulo dovrebbero rappresentare cose simili o componenti nello stesso oggetto composito.

  • Le classi strettamente connesse dovrebbero essere nello stesso modulo.

  • Le classi non connesse o debolmente connesse dovrebbero essere messe in moduli separati.

  • I moduli dovrebbero avere una buona coesione, cioè, alta cooperazione tra i suoi componenti.

  • Un modulo dovrebbe avere un basso accoppiamento con altri moduli, cioè l’interazione o l’interdipendenza tra i moduli dovrebbe essere minima.

Ottimizzazione della progettazione

Il modello di analisi cattura le informazioni logiche sul sistema, mentre il modello di progettazione aggiunge dettagli per supportare un accesso efficiente alle informazioni. Prima che un progetto sia implementato, dovrebbe essere ottimizzato in modo da rendere l’implementazione più efficiente. Lo scopo dell’ottimizzazione è di minimizzare il costo in termini di tempo, spazio e altre metriche.

Tuttavia, l’ottimizzazione del design non dovrebbe essere eccessiva, poiché anche la facilità di implementazione, la manutenibilità e l’estensibilità sono preoccupazioni importanti. Si vede spesso che un design perfettamente ottimizzato è più efficiente ma meno leggibile e riutilizzabile. Quindi il progettista deve trovare un equilibrio tra le due cose.

Le varie cose che possono essere fatte per l’ottimizzazione del design sono –

• Aggiungi associazioni ridondanti
• Ometti associazioni non utilizzabili
• Ottimizzazione degli algoritmi
• Salva gli attributi derivati per evitare di ri-computare espressioni complesse

Aggiungi associazioni ridondanti

Durante l’ottimizzazione del design, si controlla se la derivazione di nuove associazioni può ridurre i costi di accesso. Anche se queste associazioni ridondanti possono non aggiungere alcuna informazione, possono aumentare l’efficienza del modello complessivo.

Omissione di associazioni non utilizzabili

La presenza di troppe associazioni può rendere un sistema indecifrabile e quindi ridurre l’efficienza complessiva del sistema. Quindi, durante l’ottimizzazione, tutte le associazioni non utilizzabili vengono rimosse.

Ottimizzazione degli algoritmi

Nei sistemi orientati agli oggetti, l’ottimizzazione della struttura dei dati e degli algoritmi è fatta in modo collaborativo. Una volta che il disegno della classe è in atto, le operazioni e gli algoritmi devono essere ottimizzati.

L’ottimizzazione degli algoritmi si ottiene –

• Ristrutturazione dell’ordine dei compiti computazionali
• Inversione dell’ordine di esecuzione dei cicli da quello stabilito nel modello funzionale
• Eliminazione dei percorsi morti all’interno dell’algoritmo

Salvataggio e memorizzazione degli attributi derivati

Gli attributi derivati sono quegli attributi i cui valori sono calcolati in funzione di altri attributi (attributi base). Ricalcolare i valori degli attributi derivati ogni volta che sono necessari è una procedura che richiede tempo. Per evitare questo, i valori possono essere calcolati e memorizzati nelle loro forme calcolate.

Tuttavia, questo può comportare anomalie di aggiornamento, cioè, un cambiamento nei valori degli attributi di base senza un corrispondente cambiamento nei valori degli attributi derivati. Per evitare ciò, vengono prese le seguenti misure –

• Ad ogni aggiornamento del valore dell’attributo di base, anche l’attributo derivato viene ricalcolato.

• Tutti gli attributi derivati vengono ricalcolati e aggiornati periodicamente in un gruppo piuttosto che dopo ogni aggiornamento.

Documentazione del design

La documentazione è una parte essenziale di qualsiasi processo di sviluppo del software che registra la procedura di realizzazione del software. Le decisioni di progettazione devono essere documentate per qualsiasi sistema software non banale per trasmettere il progetto ad altri.

Aree di utilizzo

Anche se è un prodotto secondario, una buona documentazione è indispensabile, in particolare nelle seguenti aree –

• Nella progettazione di un software che viene sviluppato da un certo numero di sviluppatori
• Nelle strategie di sviluppo iterativo del software
• Nello sviluppo di versioni successive di un progetto software
• Per valutare un software
• Per trovare condizioni e aree di test
• Per la manutenzione del software.

Contenuti

Una documentazione utile dovrebbe essenzialmente includere i seguenti contenuti –

• Architettura di sistema ad alto livello – Diagrammi di processo e diagrammi di modulo

• Astrazioni e meccanismi chiave – Diagrammi di classe e diagrammi di oggetto.

• Scenari che illustrano il comportamento degli aspetti principali – Diagrammi comportamentali

Caratteristiche

Le caratteristiche di una buona documentazione sono –

• Concise e allo stesso tempo, non ambigue, coerente e completa

• Tracciabile alle specifiche dei requisiti del sistema

• Ben strutturata

• Diagrammatica invece che descrittiva