Un diagramma degli oggetti è un modello che mostra un insieme di oggetti, con i loro attributi a le loro relazioni, in un dato momento. È simile ad un diagramma delle classi, ma mostra oggetti (ovvero, istanze di classi) anziché classi, collegamenti (istanze di associazioni) anziché associazioni e valori (istanze di attributi) anziché attributi.
La notazione riprende quella dei diagrammi delle classi:
- un oggetto è rappresentato da un rettangolo, all'interno vi è scritto il nome simbolico per l'oggetto e il nome della classe di cui è istanza, separata da due punti: nome-oggetto : classe oppure solo : classe non è obbligatori specificare un nome simbolico per l'istanza;
- un collegamento è rappresentato da una linea che collega due oggetti, con accanto il nome dell'associazione di cui è istanza;
- un valore viene scritto nella seconda sezione del rettangolo, nella forma: nome-attributo = valore.
Le seguente figura invece mostra oggetti e collegamenti per un negozio con diversi registratori di cassa, con alcune vendite in corso e altre completate:
Modellazione di un dominio in modalità iterativa ed evolutiva...
Anche se sono state dedicati parecchi paragrafi alla descrizione di questo documento, in ciascuna iterazione la modellazione di un modello, nella realtà è di circa 30 minuti, o ancora meno se si utilizzano i pattern di analisi predefiniti.
Nello sviluppo iterativo il modello evolve in modo incrementale su diverse iterazioni.
In questa iterazione infatti ci si è dedicati a uno scenario semplificato di "pagamento in contanti" di Elabora Vendita.
Si evitino grossi sforzi per creare modelli di dominio corretti e completi.
Nella timeline di sviluppo incrementale il modello di dominio viene iniziato nella fase di elaborazione:
| Disciplina | Elaborato | Ideaz. | Elab. | Costr. | Trans. |
|---|---|---|---|---|---|
| Iterazione | I1 | E1..En | C1..Cn | T1..T2 | |
| Modellazione del business | Modello di dominio | i | |||
| Requisiti | Modello dei casi d'uso (SSD) | i | r | ||
| Visione | i | r | |||
| Specifiche supplementari | i | r | |||
| Glossario | i | r | |||
| Progettazione | Modello di progetto | i | r | ||
| Documento dell'architettura | i | r | |||
| Modello dei dati | i |
Ideazione...
I modelli non sono pienamente giustificati durante questa fase. Lo scopo dell'ideazione non è quello di effettuare un indagine serie, ma piuttosto decidere se il progetto merita un'indagine più approfondita in una fase di elaborazione.
Elaborazione...
Il modello di dominio viene creato in primo luogo durante le iterazioni dell'elaborazione, quando vi è la massima necessità di capire i concetti significativi e di rappresentarne alcuni come classi software durante il lavoro di progettazione.
Modelli concettuali nello sviluppo software...
Nello sviluppo software l'uso dei modelli concettuali è piuttosto diffuso. Non sempre i modelli concettuali vengono creati con le stesse finalità o nello stesso modo dei modelli di dominio presentati.
Nelle basi di dati viene usato un modello concettuale dei dati, di solito espresso sotto forma di un diagramma E-R. Un tale diagramma è chiamato modello dei dati e descrive le informazioni che il sistema di interesse deve gestire in modo persistente.
Diversamente da un modello dei dati, un modello di dominio deve rappresentare sia informazioni persistenti che anche transienti, e in particolare anche informazioni che il sistema deve ricordare dopo l'esecuzione di ciascun passo del caso d'uso. Invece un modello di dominio non è interessato a quelle informazioni che servono solo durante l'esecuzione dei singoli passi di un caso d'uso.
Un'altra differenza nella modellazione concettuale delle informazioni di un sistema software è la seguente. In alcuni casi, viene creato un modello per rappresentare solo le informazioni che il sistema deve conoscere e gestire direttamente. In altri casi, invece, viene creato un modello più ampio che, nello spirito di un "dizionario visuale", rappresenta tutte informazioni inerenti al dominio del problema, e che dunque può mostrare anche concetti che non devono essere gestiti o conosciuti direttamente dal sistema, ma sono utili per la comprensione.
Un modello di dominio, così come lo abbiamo descritto, è a metà strada tra un modello dei tipi di business e un modello concettuale di business. Il modello di dominio deve rappresentare tutte le informazioni persistenti e transienti che il sistema deve conoscere e gestire direttamente dal sistema se la loro inclusione favorisce la comprensione e la comunicazione.
Per esempio il modello per il sistema POS che segue può essere considerato un modello concettuale di business poiché ci sono per esempio classi come Customer e Item, di cui il sistema non deve direttamente gestire le istanze, ma utili per la comprensione:
Mentre il modello che segue è un modello dei tipi di business:
questo modello è stato ottenuto dal modello concettuale che abbiamo visto prima della figura sovrastante, in questo versione sono stati eliminati gli elementi Customer e Item non utili al sistema, riorganizzando alcune associazioni e specificando di conseguenza le loro molteplicità.