Ci sono tre metodi per portare questo obiettivo a compimento.

Questo primo approccio è generalmente il più facile dal quale iniziare e talvolta anche il migliore. Vi sono modelli di dominio già esistenti e ben congegnati per molti domini comuni: inventario, finanza, salute, ecc... Questo metodo va oltre gli obiettivi di questo libro.

Si basa sull'analisi linguistica e l'identificazioni di nomi e locuzioni nominali (ovvero di frasi formate da un nome principale insieme ai suoi aggettivi e determinanti) nelle descrizioni testuali di un dominio. Questi nomi vengono poi considerati come classi concettuali candidate o attributi.

Occorre fare attenzione: se un nome è presente nella descrizione testuale di un dominio non vuol dire che farà parte anche di un diagramma UML che lo descrive in modo visuale.

In questo contesto tornano utili i casi d'uso dettagliati.
Esempio del caso d'uso elabora vendita:

Scenario principale

1. il Cliente arriva alla cassa POS con gli articoli e/o i servizi da acquistare.
2. il Cassiere inizia una nuova vendita.
3. il Cassiere inserisce il codice identificativo di un articolo.
4. il Sistema registra la riga di vendita per l'articolo e mostra la descrizione dell'articolo, il suo prezzo, il totale parziale. Il presso è calcolato in base a un insieme di regole di prezzo.

Lo stesso si può fare con gli altri passi del flusso principale o con quello delle estensioni.

I casi d'uso sono una fonte ricca di sostantivi che dovrebbero essere modellati

Un punto debole di questo metodo è che soffre dell'imprecisione e dell'ambiguità del linguaggio naturale.

Una tecnica migliore della precedente consiste nell'identificare un elenco di classi concettuali candidate basandosi su un elenco di categorie comuni di classi concettuali, come quelle mostrate nell'immagine sotto:

Ecco un esempio per comprendere come vengono trovate e disegnate le classi.

All'inizio è normale dimenticarsi alcune classi concettuali relativamente importanti, che vengono scoperte solamente dopo. Lo scopo di un modello di dominio, adottando un approccio agile, è quello di capire e comunicare rapidamente i concetti chiave, descrivendoli in modo approssimato. L'obiettivo non è la perfezione, e i modelli agili vengono solitamente scartati presto dopo la loro creazione (se si usa una lavagna è bene scattare una foto con la rappresentazione in UML). Da questo punto di vista non è importante mantenere aggiornato il diagramma, ma questo non vuol dire che è un errore farlo. Se lo si vuole mantenere potrebbe essere utile utilizzare uno strumento per il disegno di diagrammi UML (come Umlet) e cominciare a farlo fin dall'inizio con esso, magari proiettando lo sviluppo in una lavagna.

Receipt (Ricevuta) è un termine significativo nel dominio del POS, ma potrebbe essere solo un verbale di una vendita e di un pagamento, e pertanto sarebbe un informazione ripetuta. Questo concetto andrebbe mostrato nel modello di dominio?

Sono da considerare i seguenti fattori:

• in generale, mostrare un rapporto o un verbale di altre informazioni in un modello di dominio non è utile, poiché tutte le informazioni che contiene sono derivate o duplicate da altre sorgenti. Questo è un buon motivo per escluderlo
• tuttavia, una ricevuta svolge un ruolo importante in termini di restituzioni di un articolo (in termini di regole di business) poiché fornisce al portatore della ricevuta il diritto di restituzione degli articoli acquistati. Questo è un buon motivo per mostrarla nel dominio.
  Poiché la restituzione di un articolo non è considerata in questa iterazione, Receipt sarà esclusa.
  Durante il caso d'uso che riguarda Gestisci restituzione sarebbe giustificato includerla.

Un aspetto importante della modellazione del dominio riguarda l'assegnazione di nomi agli elementi del dominio (classi, associazioni, attributi). Si ricordi che il modello ha lo scopo di essere un dizionario visivo del dominio e di definire la struttura del linguaggio che il team di sviluppo userà per comunicare con le altre parti interessate. Pertanto il modello deve possedere dei nomi significativi., che rivelano il significato o l'intenzione dei diversi elementi.

• Utilizzare nomi esistenti sul territorio: se si sviluppa un modello per le prenotazioni aeree, si assegni al cliente il nome "Passeggero", anziché il nome (troppo generico) "Cliente";
• escludere caratteristiche irrilevanti o fuori dalla portata: nel modello di dominio del Monopoly per l'iterazione 1 non vengono utilizzate le carte (come la carta "Esci gratis di prigione"), quindi non è opportuno mostrare una classe Card nel modello per questa iterazione;
• non aggiungere cose che non ci sono.

I nomi delle classi sono al singolare: Cliente, non Clienti. Lo scopo di una classe e di descrivere un elemento individuale della classe e non l'insieme di tutti gli elementi. Se un singolo elemento di una classe concettuale ha invece proprio lo scopo di rappresentare una collezione di oggetti, allora si utilizzi un nome collettivo (ma singolare) per indicare la collezione: GruppoDiPasseggeri, non Passeggeri.

Un classe descrizione contiene informazioni che descrivono qualcos'altro. Più precisamente contiene oggetti utilizzati come descrizione per gli oggetti di un'altra classe.
Per esempio: un oggetto ProductDescription per memorizzare il prezzo, la descrizione testuale e la fotografia di un oggetto Item. In questo caso è utile avere anche una associazione che collega le due classi.

Perché usarle?
La necessità è comune in molti modelli di dominio.
Si facciano le seguenti ipotesi:

• una istanza Item rappresenta un articolo fisico in un negozio, come tale, potrebbe anche avere un numero di serie;
• Un Item ha una descrizione, un prezzo e un codice identificativo, che non sono memorizzati in nessun altro luogo;
• tutti quelli che lavorano nel negozio soffrono di amnesia;
• ogni volt che viene venduto un articolo fisico reale, una istanza software corrispondente di Item viene eliminata dalla rappresentazione software del dominio.

In uno scenario del genere una istanza di Item potrebbe essere il nuovo hamburger vegetariano ObjectBurger. Il negozio li vende tutti, e ciò comporta che tutte le istanze Item di ObjectBurger vengano eliminate dalla memoria del computer.

Ora sorge un problema: se qualcuno chiede "Quanto costa ObjectBurger?", nessuno è più in grado di rispondere, perché l'informazione del prezzo dell'articolo era associata alle istanze, che sono state eliminate una volta dopo averli venduti tutti.

Un modello del genere si porta con sé alcuni problemi:

1. duplicazione dei dati (e inutile occupazione di spazio in memoria): le informazioni che riguardano la descrizione di un certo Item si ripetono per ogni istanza di esso;
2. il modello è soggetto ad errori: visto che le informazioni sono duplicate, per ogni istanza di un certo Item sarà necessario inserire il prezzo o altre informazioni simili.

Per risolvere il problema si usano le classi descrizione: si potrebbe creare una classe ProductDescription che memorizza informazioni sugli articoli. Una ProductDescription non rappresenta un Item, ma rappresenta una descrizione di informazioni sugli articoli.

Questa prima immagine sotto rappresenta la scelta non giusta di usare la descrizione di un articolo come attributo della classe Item:

Mentre la seguente mostra una classe Item che usa una classe descrizione a cui è associata:

la cardinalità indica che una ProductDescription potrebbe descrivere molte istanze di Item () e che un Item è associato a una sola ProductDescription (1).

In questo caso anche se di un oggetto Item venissero vendute tutte le sue istanze alla fine a quell'Item sarebbe comunque associata una descrizione del prodotto, anche se il prodotto effettivamente non c'è.

Come ulteriore esempio si consideri una compagnia aerea che subisce la perdita di uno dei suoi velivoli per un incidente. Si ipotizzi che tutti i voli vengano cancellati per sei mesi in attesa del completamento delle indagini. Si ipotizzi anche che quando i voli vengono cancellati, i corrispondenti oggetti software Flight vengano eliminati dalla memoria del computer. Pertanto, dopo l'incidente, tutti gli oggetti software Flight vengono eliminati.

Se l'unica registrazione sull'aeroporto di destinazione di un volo è nelle istanze software di Flight, che rappresentano voli specifici per una particolare data e ora, ne consegue che non c'è più traccia delle rotte coperte dalla compagnia aerea.

Il problema può essere risolto usando una FlightDescription che descriva un volo e la relativa rotta, anche quando un determinato volo non è attualmente programmato.

Scelta non corretta:

Scelta corretta:

Si noti che questo servizio riguarda un servizio anziché una merce.