Frage

Normalerweise bin ich so verwechselt mit UML und diese Situation ist nicht anders. Nehmen wir an, ich habe eine Schnittstelle Ianimal, Klasse Food und Katze:

interface IAnimal {
    void Feed(Food food);
}

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

Ich habe 3 Fragen zum Zeichnen von UML -Klassendiagramm für diese 3 Elemente:

  • Ich gehe davon aus, dass ich Assoziation zwischen Ianimal und Essen oder Katze und Essen verwenden sollte. Sollte es einen Pfeil auf einer Seite der Assoziationslinie geben, wenn ja, auf welcher Seite und warum?

  • Wenn ich Feed als Ianimal -Methode auf Diagramm schreibe, sollte ich dann eine Methode -Feed in der Klassenkatze schreiben oder nur zusätzliche Katzenmethoden schreibe?

  • Das Wichtigste: Sollte der Assoziation zwischen Ianimal und Nahrung, Katze und Essen oder beides sein?

War es hilfreich?

Lösung

UML definiert eine Reihe von Beziehung Typen.

Beziehungen haben eine Reihe verschiedener Notationen:

  • Assoziationsbeziehungen haben eine Basisnotation eines soliden Weges
  • Abhängigkeitsbeziehungen haben eine Basisnotation eines gestrichelten Pfeils
  • Generalisierungsbeziehungen haben eine Basisnotation eines soliden Pfades mit einer dreieckigen Pfeilspitze
  • Realisierungsbeziehungen haben eine Basisnotation eines gestrichelten Pfeils mit einer dreieckigen Pfeilspitze (eine Mischung aus Abhängigkeit und Verallgemeinerung)

Bildlich

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

              |

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

Das ist:

  • Die Beziehung zwischen IAnimal und Food ist ein Verwendungszweck Beziehung. Dies wird als Abhängigkeit mit dem Stereotyp «Verwendung» angezeigt
  • Die Beziehung zwischen IAnimal und Cat ist ein Realisierung Beziehung.

Assoziationsbeziehungen werden verwendet, um anzuzeigen Verbindungen zwischen zwei oder mehr Klassifikatoren. Dies impliziert, dass mindestens eine der Klassen eine hat Attribut des anderen Typs (oder einer Sammlung). Tatsächlich enthalten Attribute und Assoziationsendeen die gleichen Informationen und können austauscht werden.

Imho, die von Ihnen beschriebenen Beziehungen sollten also nicht als Assoziationen modelliert werden.

Andere Tipps

Unter der Annahme eines Klassendiagramms sollten Sie einen "Verwendungs" -Assoziation zwischen Ianimal und Food und einem "" Assoziation zwischen Katze und Ianimal und Hunde und Ianimal haben:

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

Wie wählerisch Sie über diese Art von Dingen sind, hängt sehr davon ab, wofür Sie UML verwenden.

Wenn Sie einen witzigen Uml-zu-Code-Übersetzer haben, müssen Sie wählerisch sein (aber es sieht so aus, als würden Sie sich mit Code wohler als mit Kästchen und Zeilen haben, also warum sollten Sie ein solches Tool verwenden?)

Wenn Sie einfach UML verwenden, um mit anderen Menschen zu kommunizieren, können Sie es sich leisten, etwas weniger wählerisch zu sein.

Craig Larmans "Anwenden von UML und Mustern" betont diesen Punkt, indem sie Diagramme einbeziehen, die so aussehen, als wären sie auf einem Whiteboard skizziert worden. Eine durchgezogene Linie, die der UML -Standard sagt, sollte in dieser Art von Diagramm in Ordnung sein. Also mit Pfeilspitzen und so weiter.

Mir ist klar, dass die Linie ausgehen sollte IAnimal zu Food.

Ob die Pfeilspitze Klarheit (für menschliche Leser) hinzufügt, ist eine Frage der Wahl, zeigt jedoch eine unidirektionale Beziehung an:

Aus Dieses einleitende Stück:

"In einer einheitlichen Vereinigung sind zwei Klassen verwandt, aber nur eine Klasse weiß, dass die Beziehung besteht."

Ich würde argumentieren, dass Ianimal ein Essen haben würde, da es metabolisiert ist, aber wenn Sie wirklich HAS-A bezeichnen möchten, sollte es je nach Diamant eine Aggregation (offener Diamant) oder ein Kompositionssymbol (gefüllt) sein, je nach der Kaskadierung löschender Eigenschaften.

Laut Martin Fowler gibt es zwei Gedankenschulen mit UML. Es gibt die "Sketchers", die die Notation auf Whiteboards und seltsame Papierstücke verwenden, um Mitarbeitern genug über ihre Ideen zu vermitteln.

Dann gibt es diejenigen, die UML als technische Zeichnungen betrachten, bei denen jedes letzte Detail eines Designs erfasst werden muss.

Ich bin fest im früheren Lager. Als ehemaliger Ingenieur kann ich Ihnen aus persönlicher Erfahrung sagen, dass UML keine echten technischen Zeichnungen hat, um ein Softwaredesign vollständig zu erfassen.

Wenn Sie zufällig an letztere glauben, machen Sie bitte einen kompletten Desktop- oder Web -UI -Design mit UML und veröffentlichen Sie es hier.

1) Zwischen der Schnittstelle Ianimal und dem Typ Food sollten keine Assoziationen geschrieben werden. Assoziationen werden nur verwendet, um Typen mit Propriities innerhalb der Klassen zu verbinden. Z.B

class Animal
{
   Food foodEaten;
}

class Food
{
 //Implementation code
}

Dann sollten Sie einen Zusammenhang schreiben, der die Verbindung zwischen diesen beiden Typen angibt.

Was Sie stattdessen zeichnen sollten, ist eine Abhängigkeit, die angibt, dass die Schnittstelle Ianimal vom Typ Food abhängt. Die Abhängigkeit ist wie die Assoziation im obigen Bild gezeichnet. Ändern Sie einfach die gerade Linie in eine gepunktete.

2) Nein, schreiben Sie diese Methoden nicht und schreiben Sie keine Abhängigkeit. Lassen Sie alle Notationen nur auf der Schnittstelle Ianimal

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top