Sollte ich Schauspieler in das Domain-Model/Class-Diagramm einsetzen?

Question

Beim Entwerfen sowohl des Domain-Modells als auch des Klassendiagramms habe ich Probleme, zu verstehen, was sie in sie einfügen sollen.

Ich werde ein Beispiel für das geben, was ich meine:

Ich mache ein Urlaubsplanerprogramm, das eine hat Administrator und End-Users. Das Administrator macht ein paar Dinge wie die Registrierung End-Users im Programm, wechseln Sie ihre Vorhersagen usw. die End-User kann seine Urlaubstage usw. wählen

Ich habe zunächst eine definiert Administrator und End-User als Konzepte im Domänenmodell und später als Klassen im Klassendiagramm. Im Klassendiagramm hatten beide Klassen ein paar Methoden wie

Administrator.RegisterNewUser();
Administrator.UnregisterUser(int id);

usw.

Erst nach einiger Zeit wurde mir klar, dass das tatsächlich beide Administrator und End-User Sind Schauspieler, und vielleicht habe ich dieses Design völlig falsch verstanden. Anstatt Administrator- und Endbenutzerklassen mit Methoden zu füllen, um die Anforderungen meiner Anwendung zu erledigen, konnte ich andere Klassen aus der Domäne definieren, um sie zu erledigen Anwendungsfall). Ich könnte eine haben UserDatabase.RegisterNewUser() und UserDatabase.UnregisterUser(int id);, Zum Beispiel, anstatt diese Methoden auf dem zu haben Administrator Klasse.

Die Idee wäre, zu versuchen, den gesamten Urlaubsscheduler als "geschlossenes Programm" zu betrachten, das eine Reihe von Funktionen hat und sich nicht mit Dingen wie Authentifizierung befasst, das intern/geschützt sein sollte, da das einzige Öffentlichkeit ist Dinge, die die Außenwelt sehen lassen, wären ihre Controller.

Ist das der richtige Ansatz? Oder verstehe ich das völlig falsch? Ist es im Allgemeinen eine schlechte Idee, Schauspieler in das Domain-Modell/die Klassendiagramme zu versetzen? Was sind gute Faustregeln dafür?

Mein Dozent folgt UML und Muster anwenden, was ich schrecklich finde, also möchte ich wissen, wo ich weitere Informationen zu dieser beschriebenen Situation für Schauspielermodelle nachschlagen kann.

Ich bin immer noch ein bisschen verwirrt über all das, da sich dieser neue Ansatz radikal von allem unterscheidet, was ich zuvor getan habe.

Answer 1

Ich würde nicht sagen, dass Ihr Design, wie Sie spekulieren, völlig falsch ist. Tatsächlich sind Administrator und Endbenutzer gültige Domänenobjekte, die in den Klassendiagrammen irgendwie dargestellt werden sollten. Nur weil Sie diese beiden Unternehmen als Akteure identifizieren, heißt das nicht, dass sie von der Domäne ausgeschlossen werden sollten. Denken Sie daran, Ihre Domain ist Ihr Umfang oder "relevanter Kontext", dh die Menge nützlicher Objekte, die eine relevante Rolle in Ihrem Spiel spielen Lösung.

Sie können mit grundlegenden Objekten beginnen, die Ihr Modell umfassen. Schreiben Sie sie einfach ohne weitere Analyse wie dem Stürmen von Hirnen auf ...

• Urlaub
• Ort
• Reisebüro
• Zeitlicher Ablauf
• Benutzer
• Reservierung
• Reservierungsservice (Dies kann eine Schnittstelle für den Zugriff auf die Ferienreservierungsmaterial sein)

Versuchen Sie dann, die Beziehungen zwischen diesen Objekten aufzubauen. Wenn Sie keine Beziehung finden können, bedeutet dies, dass Sie nicht die richtigen Objekte auswählen. Wenn sie Teil derselben Problemdomäne sind, müssen sie irgendwie verwandt sein.

Nach einiger Zeit werden Sie feststellen, dass Objekte fehlen, versuchen, so weit wie möglich zu verkapulieren und die richtigen Abstraktionen darzustellen. Entwurfsmuster können Ihnen dabei helfen.

Wenn jedes mögliche Objekt mit all seinen Eigenschaften und Methoden dargestellt wird, sollten Sie ein vollständiges, wenn noch noch nicht fertiggestelltes, funktionales Design haben.

Ich weiß, dass Sie eine Menge Theorie im Kopf haben sollten, also gehen Sie los, ohne Angst, ich selbst habe diesen Ansatz bei der Arbeit oft erfolgreich verwendet.

Endlich eine Kopie von bekommen Uml destilliert

Grüße,

Answer 2

Ich denke, Sie sollten mehr über die Domänenmodellierung und den Prozess des Erhaltens von Anwendungsfällen zu Klassendiagrammen erfahren. Akteure als Klassifikatoren können Teil der Klassendiagramme sein, für die für die Analyse und das Design verwendete Klassendiagramme modellieren jedoch das von Ihnen entwickelte System, und ein Akteur ist eine externe Entität. Wenn Sie Anwendungsfälle und Anwendungsfalldiagramme verwenden, ist es das Ziel, funktionale und nicht funktionierende Empfehlungen zu identifizieren und daher den Umfang des Systems für die Entwicklung und externe Entitäten zu definieren - Rollen oder Systeme - mit dem von Ihnen entwickelten System interagieren. In Anwendungsfalldiagrammen können Sie manchmal eine Box finden, die die Systemgrenze darstellt, die alle Anwendungsfälle umfasst, die in Ihrem System realisiert werden, die Akteure sind jedoch nicht mehr in der Box. Bei der Modellierung der Domänen vergessen Sie normalerweise das System insgesamt, da Sie die Art und Weise erfassen möchten, wie die Domäne funktioniert. Oft werden spezielle Diagramme und Modellierungselemente für die Domänenmodellierung verwendet. Wie gesagt, es geht darum, die Domäne zu verstehen, in der das System verwendet wird. Klassendiagramme in der Analyse- und Entwurfsphase beschreiben das von Ihnen entwickelnde System, sodass keine Akteure im Inneren sein können.