The Blog

Domain Model mit UML beschreiben

Möchte man Domain Modelle beschreiben, bieten sich Klassen- und Objektdiagramme in UML Notation an. Wichtig dabei ist, dass die Diagramme:

  • nur wesentliche Aspekte abbilden
  • als Abstraktion zur Implementation, nicht als eins zu eins Abbildung verwendet werden (!)
  • immer nur einen relevanten Ausschnitt zeigen.

Als Faustregel sollte man probieren Diagramme auf 7 Elemente zu beschränken,  ohne Beziehungen u. Beschreibungen.

Folgendes Diagramm bildet eine Gesprächsbasis um zu beschreiben, in welcher Beziehung Bestellung, Lieferant und Käufer in einem fiktiven Projektkontext  stehen:

  • Ein Bestellung muss einen Lieferanten haben
  • Eine Bestellung braucht keinen Käufer
  • Eine Bestellung kann nur einem Käufer zugeordnet werden.

Folgende kleine Änderung ändert die Anforderungen massiv und führt in der Implementierung zu einer sehr abweichenden Software:

Nun sagen wir:

  • eine Bestellung hat mind. einen Käufer
  • eine Bestellung kann viele Käufer haben.

Die Diagramme beschreiben die Problemwelt von sehr unterschiedlichen Unternehmen.

Diagramm 1:

  • Bestellungen können auf Vorrat gekauft werden. Es gibt eine Lagerhaltung.

Diagramm 2:

  • Bestellt wird beim Lieferanten erst, wenn die Ware auch tatsächlich an den Endkunden verkauft wurde.

Das eine Bestellung Positionen hat, einem Lager oder einem Logistiker zugeordnet, das die Bestellung einen Status hat, etc., etc. All das ist nicht nur ausgeklammert um das Beispiel klein zu halten, sondern kann für die Kommunikation über einen Teilaspekt nicht wichtig sein. Der Mehrwert von kleinen beschreiben Diagrammen besteht darin, eine schnell verständliche Gesprächsgrundlage zu haben die es auch erlaubt Erkenntnisse formalisiert (UML) festzuhalten.


Kick It auf dotnet-kicks.de

Tags: ,

5 Awesome Comments So Far

Don't be a stranger, join the discussion by leaving your own comment
  1. Mike Bild
    November 7, 2010 at 11:46 #

    Tut mir leid Robert, ich kann keinen Zusammenhang zu DDD und auch nicht zu UML erkennen.

    Du beschreibst, in einer „quasi“ UML, eine Datenstrukturbeziehungen und leitest durch eigene Interpretation Verhalten ab. Ich kann das Verhalten in Deinen Diagrammen nur durch Erläuterung erkennen. Und diese beschreibst Du in Prosa. Als Kommunikationsgrundlage für eine Datenstruktur und dessen Beziehungen zu anderen Datenstrukturen ist Deine beschriebene Notation durchaus denkbar, nur kann ich hier kein UML und auch kein modelliertes Verhalten herauslesen. Ich benötige Dich als Übersetzer, um das Verhalten in der Domain zu erfassen. Sorry!

    Zur Notation:
    Klär mich doch bitte auf, um welchen UML Diagrammtyp es sich handeln könnte. Für Klassendiagramme/Objektdiagramme fehlen wichtige Informationen wie Sichtbarkeit oder Instanzname. Ich kenne eine Entity Relationship Diagram. Das ist doch eher das, was Du beschreiben möchtest. Oder? Das ist allerdings kein UML Diagrammtyp, sondern ein Gegenstands-Beziehungs-Modell und dient einer semantischen Datenstrukturmodellierung. Im übrigen tun es aus meiner Sicht auch Kreise mit Namen und Striche mit Namen dazwischen.

    Zur Domain:
    Datenstrukturen ohne Verhaltensbeschreibung sind von Natur aus Anämisch. Will heißen, hier wird nicht die Domain, sondern ein möglicher Zustand der Domain beschrieben. Kann Dein Diagramm 2 nicht auch heißen: Eine Bestellung ist erst vollständig, wenn alle notwendigen Daten vorhanden sind? Mhh, wie ich schon sagte: In der Domain, im DDD Sinne, hilft diese Art von Diagrammen mir jedenfalls nicht wirklich weiter. Noch 3 Wochen hab ich das besprochene Verhalten vergessen und ich muss wieder Kommunizieren oder den Prosatext lesen. Für die Katz.

    Soviel erstmal, ich muss leider los.
    Gruß, Mike

  2. Robert
    November 7, 2010 at 13:15 #

    @Mike, das ist keine Quasi UML, das sind Klassendiagramme. Das Klassendiagramme viele oder gar alle Methoden/Felder haben müssen, ist ein typisches Missverständnis. Guck mal in die Beispiele auf dem passenden Wikipedia Artikel: http://en.wikipedia.org/wiki/Class_diagram

    Diagramme brauchen immer einen Übersetzer. Diagramme sind eine Kommunikationsgrundlage, nicht der Kommunikationsweg. So wird UML von Evans in seinem DDD Buch eingeführt und genutzt. Ob das Model anämisch ist steckt da auch nicht drin. Weder Evans noch Nilsson benutzen in der Mehrheit Ihrer Klassendiagramme Properties und Methoden. Du meintest ja, Du hast das Evans Buch, blättere mal ein bisschen da drin – ist wirklich empfehlenswert!

    Ob eine Bestellung erst vollständig ist, wenn alle Daten Vollständig sind, steckt nicht in dem Diagramm. Eine Aussage in dem Post ist: Diagramme sollen klein sein und einen, bzw. wenige Sachverhalte transportieren.

    • Mike Bild
      November 7, 2010 at 22:00 #

      „Ob eine Bestellung erst vollständig ist, wenn alle Daten Vollständig sind, steckt nicht in dem Diagramm.“

      Stimmt, und genau das meine ich, denn genauso wenig steckt da

      „Bestellt wird beim Lieferanten erst, wenn die Ware auch tatsächlich an den Endkunden verkauft wurde.“

      drin.

      Ein typisches Missverständnis ist vorallem, dass Klassendiagramme etwas über Verhalten und Interaktion aussagen können. Das diese jetzt Properties/Methoden haben können oder müssen habe ich mit keiner Silbe erwähnt – zudem das Diagramm auch mit Properties/Methoden anämisch bleiben kann. Erst die Beschreibung einer kohärenten Wechselwirkungen und der Semantik von System mit Subsystem – Funktionseinheit mit Funktionseinheit – schafft ein „wertvolles“ Domain Model. Das muss man Evans lassen, dass konnte er vermitteln.

      Wenn Diagramme, laut deiner Aussage, immer Übersetzer brauchen, dann können sie ohne den Übersetzer nichts transportieren. Sie wären nicht mehr, als ein Notizzettel für den Übersetzer. Sollte das der Grund für ein Diagramm sein?

      Da ich, wie ich schon sagte, Evans Buch schon ganz gut kenne, glaube ich an den Nutzwert von Klassendiagrammen zur

      Visualisierung von Prosa. Also als eine Art von Dokumentation begleitend zu Text, aber *nach* einer Modellierung nicht währendessen oder davor oder danach. Evans selbst beschreibt die Diskussion um die UML Notations als wenig hilfreich und da mach ich jetzt mal mit. Er beschreibt weiterhin, er verwendet eine nicht formelle UML Notation, um eine Kommunikationsbasis zu schaffen. Ich meine, da ist er mit seiner Form von Klassendiagrammen nicht besonders gut aufgestellt. Besser wären für diesen Zweck ER-Diagramme gewesen. Damit hätte er auch gleich keine mal UML Notationsdiskussion gehabt. 😉

      Nun egal, für viel wichtiger finde ich allerdings, und das ist das grandiose am Buch, den Einsatz von Concept Maps als Modellierungsplattform. Hier entdeckte ich für mich den wahren Wert des Buches, die grandiose Leichtigkeit mit der Evans komplexe Domainkonzepte modelliert, visualisiert und dokumentiert. Blättere auch mal ein wenig herum – es lohnt sich! 😉

      Meine Meinung ist, Diagramme sollten sich auf einem einheitlichem Abstraktionsniveau befinden (Klassendiagramme sind das nicht) und auf diesem Abstraktionsniveau das System möglichst vollständig darstellen und beschreiben können. (auch das sind Klassendiagramme nicht) Dann findet ein Diagramm einen Transport- und auch Übersetzungsweg ohne expliziten Übersetzer. Dabei ist Nachfragen und eine Erläuterung selbstverständlich erwünscht.

      -Mike

      • Robert
        November 7, 2010 at 23:02 #

        Hallo Mike,

        ich weiß nicht ob wir vom selben Buch sprechen. Evans verwendet hauptsächlich Klassendiagramme. Eine „Concept Map“ kommt im ganzen Buch nicht vor.

        Was Du vielleicht meinst sind Navigation Maps, aber die benutzt er im Buchrücken, auf S. 65 und S, 398 – nun ja – zur Orientierung, zur Navigation.

        Oder Du meinst vielleicht Kontextmaps, die werden auf S.344 eingeführt und verbinden Modelle miteinander (die wiederum aus Klassendiagrammen bestehen).

  3. Mike Bild
    November 8, 2010 at 8:13 #

    Ja genau, diese meine ich. Diese heißen zwar jetzt Concept Maps (siehe Wikipedia), tut dem Konzept jetzt aber nichts. Schau sie Dir mal genauer an.Coole Dinger finde ich ;-). Lange Rede, kurzer Sinn. Am Ende ist es wie immer eine persönliche Vorliebe wie ich was modelliere. Ich wollte Dir hier auch noch eine „andere“ Möglichkeit, eine die für mich mehr Aussagekraft hat, nennen. BG, Mike