Ist das Domain-Modell und die UML-Darstellung richtig?

Reply to Ist das Domain-Modell und die UML-Darstellung richtig? on Wed, 02 May 2007 13:09:59 GMT

rüdiger — Wed, 02 May 2007 13:09:59 GMT

Hallo,
ich muss zu einem Software-Projekt über einen Terminplaner ein Domain Modell erstellen (in Anschluss an diesen Use Case). Nun bin ich mit der ganzen Thematik wenig vertraut.

Der Termin-Planer soll folgenden Anforderungen genügen
1. Der Termin Initiator initiiert einen Termin und gibt einen Zeitraum vor und wer an dem Termin teilnehmen soll.
2. Die Software befragt alle Teilnehmer nach Wunsch Terminen in dem Zeitraum und Termine an denen sie keine Zeit haben
3. Die Software sucht mögliche Termine (unter Berücksichtigung der Wichtigkeit der einzelnen Teilnehmer) aus
4. Der Termin Initiator erhält mögliche Termine und wählt den endgültigen Termin aus und legt einen Ortes fest
5. Die Teilnehmer werden per E-Mail informiert.

Mein Domain-Modell sieht wie folgt aus: http://img110.imageshack.us/img110/5104/domainky4.png

Ich bitte um Kritik.

(Bitte nicht den Sinn von Domain Modellen oä hinterfragen!)

Reply to Ist das Domain-Modell und die UML-Darstellung richtig? on Wed, 02 May 2007 13:17:57 GMT

phlox81 — Wed, 02 May 2007 13:17:57 GMT

rüdiger schrieb:

Der Termin-Planer soll folgenden Anforderungen genügen
1. Der Termin Initiator initiiert einen Termin und gibt einen Zeitraum vor und wer an dem Termin teilnehmen soll.
2. Die Software befragt alle Teilnehmer nach Wunsch Terminen in dem Zeitraum und Termine an denen sie keine Zeit haben
3. Die Software sucht mögliche Termine (unter Berücksichtigung der Wichtigkeit der einzelnen Teilnehmer) aus
4. Der Termin Initiator erhält mögliche Termine und wählt den endgültigen Termin aus und legt einen Ort fest
5. Die Teilnehmer werden per E-Mail informiert.

Ich bitte um Kritik.

Orte haben auch "Termine", so sind Räume z.b. meistens buchbar.
So ist in meiner Abteilung der Meetingraum auch mit einem Outlookkalender im System vertreten.

Reply to Ist das Domain-Modell und die UML-Darstellung richtig? on Wed, 02 May 2007 13:44:39 GMT

rüdiger — Wed, 02 May 2007 13:44:39 GMT

Da hast du recht, das ist aber von der Aufgabenstellung nicht vorgegeben. Ich werde mal nachfragen, ob wir die Aufgabenstellung auch um solche Details erweitern können.

Reply to Ist das Domain-Modell und die UML-Darstellung richtig? on Thu, 03 May 2007 11:14:04 GMT

Gast++ — Thu, 03 May 2007 11:14:04 GMT

Hallo!

Ich muss vorrausschicken dass ich mit der Theorie der UML nicht sonderlich gut vertraut bin - ich benutze eigentlich mehr die Werkzeuge als dass ich der Methode zu folgen versuche

Ferner bin ich mir recht sicher das Konzept "Domänen-Modell" (DM) nicht verstanden zu haben; also werde ich im Folgenden sicherlich Begriffe der UML, der Booch-Methode, der ERM und der OOP ( C++ ) durcheinanderwürferln:

"Has"
Gibt es bei DM eine alternative Semantik?
"Has" korrelliert meines Wissens nach mit "Is-a" und ist alte Booch-Semantik.
Könnte es sein dass die DM-Semantik eher "contains" "aggregates" "relates" "generalizes" verwendet?
Das würde mir "UMLiger" erscheinen aber - s.o.
Leere Entitäten
Es ist mir bei "Proof-of-Concepts" und Reviews öfter angekreidet worden; nämlich wenn ich einer Klasse ( noch) keine Instanzatribute und / oder Methoden zugeornet hatte sondern sie erstmal nur aus strukturellen Überlegungen im Modell führte.
Ist das bei DM erlaubt?
<>
Im Use-Case gibt es ja einen direkten Bezug zwischen Aktoren; der ist hier nicht modelliert; es fehlt sogar der teilnehmende Aktor.
Darf oder soll das sogar so sein?
Navigabllity
Die Assoziationen ( nennt man das bei DM auch so ?) sind bidirektional; tragen aber schon Kardinalitäten.
Soll das so?
"has-each-other"
Zwischen Ort und Termin gibt es - einen Zyklus?, eine m:n relation? ...
UML : Link-Klasse?
ERM : m:n Relation
C++ : Forward Deklaration (oder am besten garnich sondern über abtrakte Basisklassen auflösen)

Darf das im DM so sein?

Das sind aber glaube ich alles eher KLeinigkeiten; ansonsten sieht das schon zienlich gut aus; die Semantik klingt methodisch sehr sauber.

Grüsse

*this

Reply to Ist das Domain-Modell und die UML-Darstellung richtig? on Thu, 03 May 2007 00:58:48 GMT

hustbaer — Thu, 03 May 2007 00:58:48 GMT

Hab jetzt nur kurz überflogen was diverse lustige Seiten im Inet zu dem Thema sagen (bin gerade erst dabei mir einige Dinge über UML anzugucken - alles was ich halt für nützlich halte), und ich denke die Assoziationen sollten nicht einfach mit "has" bezeichnet werden, sondern einfach beschreibend, also etwa so:
(Termin Initiator) -- initiiert -- (Termin)
(Teilnehmer) -- nimmt Teil -- (Termin)
(Teilnehmer) -- hat -- (Bevorzugter Zeitpunkt)
(Teilnehmer) -- hat -- (Unmöglicher Zeitpunkt)
(Termin) -- findet statt an/in -- (Ort)

Weiters denke ich sollte man Singular verwenden, also eben "unmöglicher Zeitpunkt" und nicht "Zeitpunkte". Wenn etwas (Teilnehmer) mehr als eins von etwas anderem ("Unmöglicher Zeitpunkt") haben kann drückt das ja die "multiplicity" der Assoziation aus.

Weiters denke ich der "Teilnehmer" müsste eigentlich eine "Person" sein, das was in deinem Diagramm "Teilnehmer" ist würde zu einer Assoziation an der ein Objekt (Concept) "Terminteilnahme" oder "Termineinladung" so dranhängt, und dieses Objekt (Concept) hat dann die Assoziation zu "Bevorzugter Zeitpunkt" und "Unmöglicher Zeitpunkt" (kann ja leicht sein dass sich die unmöglichen Zeitpunkte je nach Termin unterscheiden, z.B. WEIL man schon einen anderen Termin zu einem bestimmten Zeitpunkt hat).

Ohne diese Auftrennung würde eine real existierende Person bei dir mehreren "Teilnehmern" zugeordnet sein können (man kann ja mehr als einen Termin haben *g*), und das ist denke ich kein "natürlicher" Gebrauch des Wortes "Teilnehmer".

"Termin Initiator" wird dann auch zur "Person", "Person" hat also 2 verschiedene Assoziationen zu "Termin", nämlich einmal "initiiert von" und einmal "nimmt teil".

Allerdings verstehe ich davon auch nicht so recht viel, bzw. bin mir bei 99% nicht sicher ob ich es so verstanden habe wie es gemeint war, aber naja. Vielleicht ist ja trotzdem was dabei was dir weiterhilft.