Question

Je suis généralement si confus avec UML et cette situation n’est pas différente. Disons que j'ai une interface IAnimal, classe Food and Cat:

interface IAnimal {
    void Feed(Food food);
}

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

J'ai 3 questions sur la création d'un diagramme de classes UML pour ces 3 éléments:

  • Je suppose que je devrais utiliser l'association entre IAnimal et Food ou Cat and Food. Devrait-il y avoir une flèche sur un côté de la ligne d'association, si oui, de quel côté et pourquoi là?

  • si j'écris Feed en tant que méthode IAnimal sur un diagramme, dois-je écrire une méthode Feed dans la classe Cat ou dois-je écrire uniquement des méthodes Cat supplémentaires?

  • le plus important: l’association devrait-elle être établie entre IAnimal et Food, Cat et Food, ou les deux?

Était-ce utile?

La solution

UML définit un certain nombre de types de relations .

Les relations ont un certain nombre de notations différentes:

  • Les relations d'association ont la notation de base d'un chemin solide
  • Les relations de dépendance ont la notation de base d'une flèche en pointillé
  • Les relations de généralisation ont la notation de base d'un chemin solide avec une pointe de flèche triangulaire
  • Les relations de réalisation ont la notation de base d'une flèche pointillée avec une tête de flèche triangulaire (un mélange de dépendance et de généralisation)

picturialement

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

              |

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

C'est-à-dire:

  • La relation entre IAnimal et Alimentation est une relation d'utilisation . Ceci est montré comme une dépendance avec le stéréotype «use»
  • La relation entre IAnimal et Cat est une réalisation .
Les

relations d'association sont utilisées pour indiquer des connexions entre deux classificateurs ou plus. Cela implique qu'au moins une des classes possède un attribut de l'autre type (ou une collection). En fait, les attributs et les extrémités d’association contiennent les mêmes informations et peuvent être échangés.

Ainsi, à mon humble avis, les relations que vous décrivez ne doivent pas être modélisées comme des associations.

Autres conseils

En supposant un diagramme de classes, vous devriez avoir un "use" association entre IAnimal et Food et un "est un" association entre Cat et IAnimal et Dog et IAnimal:

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

Votre point de vue sur ce genre de choses dépend dans une large mesure de la raison pour laquelle vous utilisez UML.

Si vous avez une sorte de traducteur sifflant UML en code, vous devez être difficile (mais il semble que vous soyez plus à l'aise avec le code qu'avec les boîtes et les lignes - alors pourquoi voudriez-vous utiliser un tel outil? )

Si vous utilisez simplement le langage UML pour communiquer avec d'autres personnes, vous pouvez vous permettre d'être un peu moins difficile.

Craig Larman's "Application d'UML et de modèles" souligne ce point en incluant des diagrammes qui semblent avoir été dessinés sur un tableau blanc. Une ligne continue qui, selon le standard UML, devrait être en pointillé convient parfaitement dans ce type de diagramme. Donc, avec des pointes de flèche et ainsi de suite.

Il est clair pour moi que la ligne doit passer de IAnimal à Alimentation .

Si la pointe de la flèche ajoute de la clarté (pour les lecteurs humains) est une question de choix, mais cela indique une relation unidirectionnelle:

De cette introduction:

  

"Dans une association unidirectionnelle, deux   les classes sont liées, mais un seul   la classe sait que la relation   existe. "

Je dirais que IAnimal aurait HAVE-A Food, puisqu'il est métabolisé, mais si vous voulez vraiment désigner HAS-A, je pense que cela devrait être un symbole d'agrégation (diamant ouvert) ou de composition (diamant rempli), en fonction des caractéristiques de suppression en cascade.

Selon Martin Fowler, il existe deux courants d’idées avec UML. Il y a les "dessinateurs", qui utilisent la notation sur les tableaux blancs et les morceaux de papier impairs pour communiquer suffisamment de leurs idées à d'autres développeurs.

Il existe ensuite ceux qui considèrent UML comme des dessins techniques, dans lesquels tous les détails d'une conception doivent être capturés.

Je suis fermement dans l'ancien camp. En tant qu'ancien ingénieur, je peux vous dire par expérience personnelle qu'UML n'a pas le pouvoir de véritables dessins d'ingénierie pour capturer complètement une conception logicielle.

Si vous croyez en ce dernier point, créez une interface utilisateur complète pour le bureau ou le Web en utilisant UML et postez-la ici.

1) Aucune association ne doit être écrite entre l'interface IAnimal et le type Food. Les associations ne sont utilisées que pour connecter des types avec des propriétés à l'intérieur de classes. E.G

class Animal
{
   Food foodEaten;
}

class Food
{
 //Implementation code
}

alors vous devriez écrire une association indiquant la connexion entre ces deux types.

Ce que vous devez dessiner à la place est une dépendance indiquant que l'interface IAnimal dépend du type Food. La dépendance est dessinée de la même façon que l'association dans l'image ci-dessus, il suffit de changer la ligne droite en une ligne en pointillé.

2) Non, n'écrivez pas ces méthodes et n'écrivez pas de dépendances. Laissez toutes les notations uniquement sur l'interface IAnimal

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top