Un attributo di una classe (concettuale) rappresenta un valore (un dato) degli oggetti di quella classe. È utile identificare gli attributi delle classi concettuali necessari per soddisfare i requisiti informativi per gli scenari correnti in corso di sviluppo.
In un modello di dominio, si includano gli attributi suggeriti dai requisiti (per esempio, i casi d'uso) e dalla necessità di ricordare valori o dati.
Per esempio, una ricevuta (che riporta le informazioni di una vendita) nel caso d'uso Elabora Vendita normalmente comprende, una data, un'ora, il nome e l'indirizzo del negozio e l'ID del cassiere. Pertanto:
Gli attributi vengono mostrati nella seconda sezione del rettangolo che rappresenta l'oggetto del mondo reale.
Un'altra notazione abbastanza utilizzata è anche la seguente:
Come si vede nel riquadro più a destra, è possibile specificare la presenza opzionale per un valore. o il numero di elementi che possono appartenere ad un attributo collezione. Per esempio, di una persona è richiesto nome e cognome, ma il secondo nome è opzionale. Quindi è indicato come si vede sopra.
Si noti che middleName : [0..1] è un requisito o una regola di dominio, incorporata nel modello di dominio. Sebbene questo sia semplicemente un modello di dominio, dal punto di vista concettuale, probabilmente un tale requisito implica che, dal punto di vista software, sia consentito un valore mancante per middleName nell'interfaccia utente, negli oggetti e nella base di dati.
Alcuni modellatori accettano che queste specifiche siano lasciate solo nel modello di dominio; questo però è un metodo dispersivo e può portare a errori, poiché ci sono persone che tendono a non guardare il modello di dominio in maniera dettagliata o come guida per i requisiti.
Si suggerisce quindi di riportare tutti questi termini relativi agli attributi nel glossario.
Talvolta gli attributi possono essere derivati, ovvero possono essere calcolati o derivati da altri elementi presenti nel modello di dominio. Per esempio, l'attributo total di Sale può essere calcolato o derivato dalle informazioni contenute negli oggetti SalesLineItem associati. In UML, per mostrare che un attributo è derivato, va usata la convenzione di indicare il simbolo "/" (oppure "|"). È conveniente mostrare solo attributi derivati che siano effettivamente significativi nel dominio.
Un altro esempio può essere quello di un cassiere che riceve un gruppo di articoli simili (per esempio 6 confezioni di tofu), inserisce l'itemID una sola volta e inserisce una quantità (6). Di conseguenza, un singolo SalesLineItem può essere associato a più istanze di Item.
La quantità inserita dal cassiere può essere registrata come attributo di SalesLineItem. Tuttavia può anche essere calcolata dall'effettivo valore della molteplicità dell'associazione, e pertanto potrebbe essere rappresentata come attributo derivato, ovvero un attributo che può essere derivato da altre informazioni.
Informalmente, la maggior parte degli attributi dovrebbe essere di un tipo di dato "primitivo", come per esempio numeri, stringhe e booleani. Non dovrebbe essere di un tipo complesso.
==Per esempio, nella figura sotto, l'attributo currentRegister della classe Cashier non è opportuno, poiché il suo tipo dovrebbe essere Register, che non è un tipo di dato semplice. Il modo migliore per esprimere il fatto che un Cashier utilizza un Register è tramite un'associazione, non un attributo. ==
Spesso può succedere che, durante la creazione di un modello di dominio, si rappresenta qualcosa come un attributo mentre invece dovrebbe essere rappresentato come una classe concettuale e un'associazione.
Classi concettuali vanno correlate con associazioni, non con attributi.
Si tenga in considerazione durante la creazione del modello di dominio la seguente regola:
se nel mondo reale non pensiamo a un concetto X come ad un numero, un testo o a un valore di tipo di dato, allora probabilmente X è una classe concettuale, non un attributo.
Se ciò che si deve rappresentare è un oggetto complesso, allora è una classe concettuale.
Con tipo di dato ci riferiamo a tipi primitivi: booleani, numeri, caratteri, stringhe ed enumerazioni (come size = {small, large}). I test di uguaglianza non sono basati sull'identità, bensì sul valore. Per esempio, di solito non ha senso distinguere tra:
Per contro, ha senso distinguere (in base all'identità dell'oggetto) tra due istanze Person distinte i cui nomi sono entrambi "Jil Smith", poiché le due istanze possono rappresentare persone diverse che hanno casualmente lo stesso nome.
Inoltre, i valori dei tipi di dato sono solitamente immutabili. Un'istanza di Person potrebbe cambiare il proprio lastName per diversi motivi.
Errore comune consiste nell'aggiungere un attributo di chiave esterna, come viene fatto nella progettazione (logica) delle basi di dati relazionali. Gli attributi non devono essere usati per correlare diverse classi concettuali nel modello di dominio.