uml - simbologia - relaciones entre clases y objetos en java
¿Cómo describir un mapa contenido en el diagrama de clases UML? (6)
En primer lugar, I y algunos otros piensan que UML debería contener algunos tipos básicos de colección, como lo hizo en algunas versiones anteriores. Se podrían tomar, por ejemplo, de la OCL ...
La "forma de EMF" parece correcta, sin embargo, le da a imho demasiada importancia al tipo, lo cual no es realmente importante, así que lo modelaría solo como una clase de asociación. Esto le permitirá capturar todas las restricciones específicas del mapa (como por ejemplo, la multiplicidad) que se pueden capturar usando una clase regular, pero no hará que esa clase sea tan importante como las otras.
Tengo una clase MyServer que contiene un mapa cuyas claves son objetos MyClientType y cuyos valores son objetos MyClient. Me gustaría describir esta relación en un diagrama de clase, pero no puedo encontrar una manera clara de hacerlo.
La respuesta de Kru es la mejor, pero aún así solo sugiere un Mapa.
Yo diría que depende del nivel de abstracción en el que se encuentra el diagrama. Si es relativamente alto, me gustaría ir con la respuesta del chimpancé. Si es relativamente bajo y realmente necesita mostrar un mapa, mostrando intencionalmente los detalles relacionados con la implementación, me gustaría seguir con lo siguiente:
MyServer
|
|
Map
|
|*
T1toT2
/ /
1/ /1
Key Value
La forma en que se implementa el mapa en el código es totalmente irrelevante (los objetos en tiempo de ejecución T1toT2 podrían no llegar a ser).
Como lo mencionó Gabreil, esto también podría ser modelado usando una clase de asociación
MyServer
|
|
Map
|
|*
T1toT2
|
|
1--------1
Key Value
Por supuesto, solo es importante si realmente necesitas mostrar o especificar un mapa.
Puede utilizar una asociación calificada:
┌──────────┐ 1 ┌───────┐
│ MyServer │Key│───────────│ Value │
└──────────┘ └───────┘
Consulte: http://etutorials.org/Programming/UML/Chapter+6.+Class+Diagrams+Advanced+Concepts/Qualified+Associations/ (porque es difícil dibujar usando ASCII)
Tenga en cuenta también que una asociación calificada cambia la multiplicidad:
┌──────────┐ 0..* ┌───────┐
│ MyServer │───────────────│ Value │
└──────────┘ └───────┘
┌──────────┐ 1 ┌───────┐
│ MyServer │Key│───────────│ Value │
└──────────┘ └───────┘
La parte superior ilustra una asociación de un servidor a valores 0-n. En contraste, la asociación calificada dice que cualquier clave dada se asociará con un solo valor, y que no se puede tener una clave o un valor ausente.
Simplemente mostraría una asociación de MyServer a MyClient con una multiplicidad de 0 .. * en el extremo MyClient. Todo lo demás es detalle de implementación y se puede dejar al programador.
MyServer
|
|
|
Map
|
| |
| |
MyClientTypeKey MyClientType
¿No debería ser tan sencillo como el anterior?
- MyServer tiene una relación uno a uno con el mapa
- El mapa tiene 1 a muchas asociaciones con las claves y los valores.
MyServer
|
|*
T1toT2
/ /
1/ /1
Key Value
La diferencia con la solución de Mark es que el servidor tiene muchas relaciones con los contenedores. También es así como Eclipse Modeling Framework (EMF) propone implementar mapas .
También puede incluir más cosas específicas de UML, como especificar que las claves deben ser únicas (a través de estereotipos).