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 clases, pero no puedo encontrar una manera limpia de hacerlo.¿Cómo describir un mapa contenido en el diagrama de clases UML?
MyServer
|
|
|
Map
|
| |
| |
MyClientTypeKey MyClientType
¿No debería ser tan simple como el anterior?
Simplemente mostraría una asociación de MyServer a MyClient con una multiplicidad de 0 .. * en MyClient. Todo lo demás es detalles de implementación y se puede dejar al programador.
Esta es una de las dos respuestas correctas. El otro es @Kru. –
MyServer
|
|*
T1toT2
/ \
1/ \1
Key Value
La diferencia con la solución de Mark es que el servidor tiene muchas relaciones con los contenedores. Así es también como el Eclipse Modeling Framework (EMF) proposes to implement maps.
También puede agregar algunas cosas más específicas de UML, como especificar que las claves tienen que ser únicas (mediante estereotipos).
En primer lugar, y algunos otros piensan, UML debe contener algunos tipos de colecciones básicas, como lo hizo en algunas versiones anteriores. Podrían tomarse por ejemplo del OCL ...
El "camino EMF" parece correcto, sin embargo, en mi humilde opinión le da demasiada importancia al tipo de , que es muy poco importante en mi humilde opinión, por lo que se acaba de modelarlo 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 utilizando clases regulares, pero no hará que esa clase sea tan importante como las otras.
Puede utilizar una asociación cualificada:
┌──────────┐ 1 ┌───────┐
│ MyServer │Key│───────────│ Value │
└──────────┘ └───────┘
Ver: http://etutorials.org/Programming/UML/Chapter+6.+Class+Diagrams+Advanced+Concepts/Qualified+Associations/(causa es difícil dibujar usando ASCII)
Tenga en cuenta también que una asociación cualificado cambia la multiplicidad:
┌──────────┐ 0..* ┌───────┐
│ MyServer │───────────────│ Value │
└──────────┘ └───────┘
┌──────────┐ 1 ┌───────┐
│ MyServer │Key│───────────│ Value │
└──────────┘ └───────┘
La parte superior muestra una asociación de un servidor a valores 0-n. Por el contrario, la asociación calificada dice que cualquier clave dada se asociará con un solo valor, y que no puede tener una clave como valor ausente.
Esta es una de las dos respuestas correctas. El otro es @ chimp's. –
Si MyServer se "expandió" para mostrar operaciones y atributos, ¿qué iría dentro del compartimiento de atributos de MyServer para modelar la relación del mapa? –
La respuesta de Kru es la mejor, pero todavía solo insinúa un Mapa.
Yo diría que depende del nivel de abstracción en el que se encuentre el diagrama. Si es relativamente alto, me gustaría ir con la respuesta del chimpancé. Si es relativamente baja y realmente se necesita para mostrar un mapa, mostrando intencionadamente detalle relativas a la aplicación, me gustaría ir con lo siguiente:
MyServer
|
|
Map
|
|*
T1toT2
/ \
1/ \1
Key Value
¿Cómo se lleva a cabo a continuación, el mapa en código es totalmente irrelevante (Run-T1toT2 los objetos de tiempo pueden no serlo en realidad).
Como se ha mencionado por Gabreil, esto podría ser también ser modelado utilizando una clase de asociación
MyServer
|
|
Map
|
|*
T1toT2
|
|
1--------1
Key Value
Por supuesto, es sólo importa si realmente realmente necesita para mostrar o especificar un mapa.
Eso es lo primero que se me vino a la cabeza, pero parece que el mapa no merece ser una clase. Es solo un método de contención. No lo sé, simplemente no me siento bien. – gooli
Pero solo digamos que tener las clases de clave y tipo directamente asociadas con MyServer no muestra cómo están relacionadas. El mapa es un contenedor pero también muestra la relación entre la clave y el tipo. – Mark