Quando si elaborano diagrammi di classi veloci, sono spesso in perdita come rappresentare le classi che vengono utilizzate solo per passare i dati tra le varie parti del programma. Li ho messi nel bel mezzo del nulla, in modo che altre persone possano vedere quale sia la classe nei parametri / ritorni. È questo il modo corretto per farlo?
(Sembrano orribilmente soli da soli.)
Non penso che ci sia uno standard stabilito. Alcuni strumenti CASE possono essere schizzinosi, ma la maggior parte degli ingegneri del software utilizza UML per progettare, non per generare codice, nel qual caso l'obiettivo è aumentare l'efficacia della comunicazione.
Ho scoperto che la presenza di oggetti che trasportano dati, specialmente se sono usati solo in argomenti di metodo e valori di ritorno, tende a oscurare le interazioni importanti.
Ecco cosa farei:
Se si utilizzano queste classi in più posizioni, è spesso corretto scegliere un'area separata del diagramma come "legenda" e organizzare queste classi in ordine alfabetico. Non c'è bisogno di ingombrare il diagramma con questi o con frecce extra - il ripetuto nelle firme è sufficiente. Rendi più facile per qualcuno trovarli. Un foglio di legenda separato (se si usano i tabelloni) è particolarmente buono.
Se la classe è usata solo nella comunicazione tra un insieme molto piccolo di classi, allora potrebbe avere più senso collocarla da qualche parte sulle linee di interazione tra di loro.
Infine, se i tuoi oggetti dati sono usati per comunicare tra livelli (ad es. dati serializzati tra client e server), potresti voler disegnare ciascun livello su un lato separato e metterlo in linea nel mezzo.
Oh, e se le relazioni dei dati all'interno degli oggetti che trasportano dati sono complesse, non esitare a usare le ERD o la notazione relativa al tuo database preferito nel diagramma delle classi. L'obiettivo è progettare, non concentrarsi sul formalismo.
Le classi senza comportamento sono generalmente chiamate oggetti di dati . Non c'è niente di sbagliato nel disegnarli come qualsiasi altra classe, e la loro solitudine potrebbe darti qualche idea per migliorare il design generale. Il fatto che gli oggetti dati siano passati potrebbe implicare che i concetti che rappresentano siano in qualche relazione con le classi esistenti. Forse dovrebbero anche contenere alcune logiche di business significative e cessare di essere oggetti dati dopotutto.
In alternativa, potresti utilizzare la relazione UML generica dipendenza per renderli meno soli. È rappresentato da una linea tratteggiata con una freccia all'estremità rivolta verso l'oggetto dati.
Leggi altre domande sui tag object-oriented uml diagrams