Pregunta

Normalmente me confundo con UML y esta situación no es diferente. Digamos que tengo una interfaz IAnimal, clase Food and Cat:

interface IAnimal {
    void Feed(Food food);
}

class Cat : IAnimal {
    void Feed(Food food) {
        //code
    }
}

Tengo 3 preguntas sobre el dibujo del diagrama de clase UML para estos 3 elementos:

  • Supongo que debería usar la asociación entre IAnimal y Food o Cat and Food. ¿Debería haber una flecha en un lado de la línea de asociación, si es así, entonces en qué lado y por qué hay?

  • si escribo Feed como un método IAnimal en el diagrama, ¿debo escribir un Feed en la clase Cat o solo escribo métodos Cat adicionales?

  • lo más importante: ¿debería ser la asociación entre IAnimal y Food, Cat y Food, o ambos?

¿Fue útil?

Solución

UML define una serie de tipos de relación .

Las relaciones tienen varias notaciones diferentes:

  • Las relaciones de asociación tienen una notación base de una ruta sólida
  • Las relaciones de dependencia tienen una notación básica de una flecha discontinua
  • Las relaciones de generalización tienen una notación base de una ruta sólida con una punta de flecha triangular
  • Las relaciones de realización tienen una notación básica de una flecha discontinua con una punta de flecha triangular (una mezcla de dependencia y generalización)

Pictorialmente

+---------------------------+
|       <<interface>>       |
|           IAnimal         |
+---------------------------+                        +--------+
| + Feed(food: Food) : void |- - - - <<use>> - - - ->|  Food  |
+---------------------------+                        +--------+
              ^
             /_\
              |

              |

              |
        +-----------+
        |    Cat    |
        +-----------+

Eso es:

  • La relación entre IAnimal y Food es una relación de uso . Esto se muestra como una dependencia con el estereotipo & # 171; use & # 187;
  • La relación entre IAnimal y Cat es una relación de realización .

Las relaciones de asociación se utilizan para indicar conexiones entre dos o más clasificadores. Esto implica que al menos una de las clases tiene un atributo del otro tipo (o una colección). De hecho, los atributos y los extremos de asociación contienen la misma información y se pueden intercambiar.

Entonces, en mi humilde opinión, las relaciones que describe no deben modelarse como asociaciones.

Otros consejos

Suponiendo un diagrama de clase, deberías tener un " uso " La asociación entre IAnimal y Food y un " es un " asociación entre Cat e IAnimal y Dog e IAnimal:

    IAnimal ----> Food
     ^   ^
    //   \\
   //     \\
 Cat      Dog

Lo delicado que eres con este tipo de cosas depende en gran medida de para qué usas UML en primer lugar.

Si tiene algún tipo de traductor UML a código, entonces necesita ser delicado (pero parece que está más cómodo con el código que con los cuadros y las líneas, ¿por qué usaría esa herramienta? )

Si simplemente estás utilizando UML para comunicarte con otras personas, entonces puedes permitirte ser un poco menos exigente.

"Aplicar UML y patrones" de Craig Larman subraya este punto, al incluir diagramas que parecen haber sido dibujados en una pizarra. Una línea sólida que el estándar UML dice que debe estar punteada está bien en ese tipo de diagrama. Así que con puntas de flecha y así sucesivamente.

Para mí está claro que la línea debe ir desde IAnimal a Food .

Si la punta de flecha agrega claridad (para los lectores humanos) es una cuestión de elección, pero indica una relación unidireccional:

De esta pieza introductoria:

  

" En una asociación unidireccional, dos   Las clases están relacionadas, pero solo una.   La clase sabe que la relación.   existe. "

Argumentaría que IAnimal tendría HAVE-A Food, ya que se metaboliza, pero si realmente quiere denotar HAS-A, creo que debería ser una agregación (diamante abierto) o un símbolo de composición (relleno de diamante), Dependiendo de las características de eliminación en cascada.

Hay dos escuelas de pensamiento con UML, según Martin Fowler. Están los "dibujantes" que usan la notación en las pizarras blancas y piezas de papel impares para comunicar lo suficiente de sus ideas a otros desarrolladores.

Luego están aquellos que ven a UML como dibujos de ingeniería, donde se debe capturar hasta el último detalle de un diseño.

Estoy firmemente en el antiguo campamento. Como antiguo ingeniero, puedo decirle por experiencia personal que UML no tiene el poder de los dibujos de ingeniería reales para capturar completamente un diseño de software.

Si cree en esto último, realice un diseño completo de UI de escritorio o web con UML y publíquelo aquí.

1) No se deben escribir asociaciones entre la interfaz IAnimal y el tipo Food. Las asociaciones solo se utilizan para conectar tipos con propiedades dentro de las clases. E.G

class Animal
{
   Food foodEaten;
}

class Food
{
 //Implementation code
}

entonces debes escribir una asociación que indique la conexión entre esos dos tipos.

Lo que debe dibujar en su lugar es una dependencia que indica que la interfaz IAnimal depende del tipo de Alimentación. La dependencia se dibuja igual que la asociación en la imagen de arriba, solo cambia la línea recta a una punteada.

2) No, no escriba esos métodos y no escriba dependecies. Deje todas las anotaciones solo en la interfaz IAnimal

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top