Von UML zu C++ (Analysemuster "Wechselnde Rollen")



  • @GMgenia sagte in Von UML zu C++ (Analysemuster "Wechselnde Rollen"):

    Ich meine die Umsetzung eines Analysemuster zu Code.

    OK.

    Dabei sind jetzt zwei Dinge wichtig:

    1. Diese Umsetzung erfolgt nicht direkt sondern in mehreren Schritten: Erstmal baust du mit Hilfe der in der Analyhsphase ermittelten Muster ein Design. Und dann baust du aus dem Design halt Code. Wobei auch das wieder ein mehrstufiger Prozess ist, denn als erstes sollte man sich mal überlegen welche Werkzeuge (Sprachen, fertige Komponenten wie Libraries/Datenbanken etc.) man verwenden sollte.
    2. Der Prozess so einer Umsetzung ist nicht eindeutig.

    Beispiele für solche Umsetzungen sind sehr hilfreich dabei zu verstehen wie ein bestimmtes Muster gemeint ist. Aber nicht geeignet dafür sie zu lernen und dann 1:1 in Programme reinzutippen.



  • @Swordfish Es geht nicht um die Analysephase. Es geht um die OOA-Musterlösungen.

    In meinem Buch steht dazu:
    "Ein OOA-Muster (also objektorientierter Analysemuster) ist ein Ausschnitt aus vorhandenen OOA-Modellen, dessen Implementierung sich in der Praxis bereits bewährt hat und entsprechend als standardisierte Lösung angesehen werden kann.
    Sie haben die Möglichkeit, sowohl allgemeine Muster als auch Muster zu verwenden, die für spezielle Szenarien vorgesehen sind und deren Einsitzt nur dort sinnvoll erscheint.

    Ein Muster besteht aus einer Gruppe von Klassen, die festgelegte Verantwortlichkeiten und Interaktionen besitzen.

    Mit dem Einsatz von Mustern tritt der Erstellungsprozess bereits in die Phase des OOD (objekt-orientiertes-Design) über."

    Das ist genau was ich versuche zu tun.

    Ich will gerne wissen ob die Übertragung, der vorherigen Definition folgend, die ich von dem Muster "wechselnde Rollen" zu Code gemacht habe, passend wäre oder ob diese Übertragung anders wäre, also, ob das Muster anderes zu interpretieren ist.



  • @GMgenia sagte in Von UML zu C++ (Analysemuster "Wechselnde Rollen"):

    Ich will gerne wissen ob die Übertragung, der vorherigen Definition folgend, die ich von dem Muster "wechselnde Rollen" zu Code gemacht habe, passend wäre oder ob diese Übertragung anders wäre, also, ob das Muster anderes zu interpretieren ist.

    Da fehlt ein ganzer Schritt. Das Design!



  • @hustbaer Das klärt einige meiner Fragen.



  • @GMgenia sagte in Von UML zu C++ (Analysemuster "Wechselnde Rollen"):

    ch will gerne wissen ob die Übertragung, der vorherigen Definition folgend, die ich von dem Muster "wechselnde Rollen" zu Code gemacht habe, passend wäre oder ob diese Übertragung anders wäre, also, ob das Muster anderes zu interpretieren ist.

    Dazu hab ich dir ja bereits einen etwas längeren Beitrag geschrieben.

    Und es gibt noch weitere Dinge die in deiner Umsetzung keinen Sinn machen.

    z.B. was soll die Funktion definiertBesucher darstellen? Und der Code in Besucher::Besucher(Besucherrolle& typBesucher) ist auch völlig sinnfrei. Was mich wieder dazu bringt dass Beispiele realistisch sein müssen.

    Entweder du lässt erstmal alle Vorgänge weg und beschränkst dich darauf die Daten zu modellieren. Dann wirst du in deinem C++ Code keine Funktionen haben.

    Oder du brauchst realistische Vorgänge die du modellieren willst.
    Und dass jeder Besucher initial mit einer von aussen definierten Besucherrolle startet, zusätzlich aber immer die Rolle Künstler einnimmt, ist nicht realistisch.



  • @Swordfish Das Design ist oben gezeichnet und beschrieben, wie fast wie es im Buch steht...



  • @GMgenia sagte in Von UML zu C++ (Analysemuster "Wechselnde Rollen"):

    @Swordfish Das Design ist oben gezeichnet und beschrieben, wie fast wie es im Buch steht...

    "Fast wie" ist bei solchen Fragen fast immer schlecht 😉



  • @hustbaer Ja, die habe ich eben erst gelesen. Und fand es ausführlich und gut. Habe darauf geantwortet. Diese Antwort klärt Fragen. Aber es bleiben bei mir weiterhin Fragen offen:

    Diese Muster enthält keine weiteren Klassen, nach dem Design und Beschreibung die im Buch gegeben sind (oder hier im Link Seite 95: http://www.sws.bfh.ch/~amrhein/Balzert-Heide.pdf). Also dürfte ich hier keine Veranstaltung-Klasse ergänzen, sofern ich die Idee dieser Muster richtig verstanden haben.

    Zum anderen frage ich mich noch immer ob die Implementierung mit dem Vector der ein Pointer auf Basisklasse ist um, durch ihn, auf auf die Kindklassen zuzugreifen) für dieses Muster angebracht wäre oder nicht. Ich denke das dass meine Kernfrage ist.



  • @hustbaer Es ist wirklich im Buch so. Es steht nur eine dritte erbende Klasse Mitarbeiter im UML Diagramm die ich mir hier gespart habe, weil es auf das selbe hinausläuft.



  • @hustbaer sagte in Von UML zu C++ (Analysemuster "Wechselnde Rollen"):

    z.B. was soll die Funktion definiertBesucher darstellen? Und der Code in Besucher::Besucher(Besucherrolle& typBesucher) ist auch völlig sinnfrei. Was mich wieder dazu bringt dass Beispiele realistisch sein müssen.

    Ja, genau darauf bezieht sich im Kern meine Frage. Die Idee dahinter es folgende:

    Es scheint mir, dass die Kardinalität (*) am Besten mit Vektoren umzusetzen wäre, so dass von den Objekten die dieser Kardinalität zugeordnet wären, beliebig viele erstellt werden könnten. Wie ich dieses Muster interpretiere sollte in der Klasse Besucher die Möglichkeit bestehen beliebig viele "Besucherrollen" anzulegen. Im Beispiel sind es zwei: Gast und Künstler. Es könnten aber 5 oder 10 sein, oder eben beliebig viele.

    Im Konstruktor habe ich eben diese zwei Rollen in den Vektor gelegt, zur Veranschaulichung für mich, dass eben beliebig viele Rollen angelegt werden könnten.

    Genau hier bin ich mir nicht sicher ob ich das Problem irgendwie falsch vestehe.



  • @GMgenia sagte in Von UML zu C++ (Analysemuster "Wechselnde Rollen"):

    Diese Muster enthält keine weiteren Klassen, nach dem Design und Beschreibung die im Buch gegeben sind (oder hier im Link Seite 95: http://www.sws.bfh.ch/~amrhein/Balzert-Heide.pdf).

    In dem von dir verlinkten Beispiel ist es keine 3. Klasse sondern ein einfaches Attribut "Zeitraum". In deinem Beispiel ist das aber nicht ausreichend. Es kann ja mehrere Veranstaltungen zur selben Zeit geben. Natürlich kann ein Besucher schwer gleichzeitig auf mehreren Veranstaltungen sein. Trotzdem wäre dort die Unterscheidung anhand des Zeitraums nicht sinnvoll. Sondern eben die Unterscheidung anhand der Veranstaltung.

    Wichtig dabei ist: verstehst du worum es dabei geht? Denn dieses einschränkende Attribut ist ein wichtiges Thema bei dem Muster "Wechselnde Rollen".

    Zum anderen frage ich mich noch immer ob die Implementierung mit dem Vector der ein Pointer auf Basisklasse ist um, durch ihn, auf auf die Kindklassen zuzugreifen) für dieses Muster angebracht wäre oder nicht. Ich denke das dass meine Kernfrage ist.

    Es ist eine mögliche Umsetzung der 1:N Beziehung. Ob es die angebrachte Umsetzung ist lässt sich nur anhand des Musters nicht beantworten. Dazu muss man mehr Dinge darüber wissen was das Programm alles machen soll.

    Es ist wirklich im Buch so. Es steht nur eine dritte erbende Klasse Mitarbeiter im UML Diagramm die ich mir hier gespart habe, weil es auf das selbe hinausläuft.

    Und welche Attribute hat dort die Basisklasse Besucherrolle? Da muss irgendwas sein das dazu dient die "gültigkeit" dieser Rolle einzuschränken. Also entweder die Veranstaltung oder ein Datum/Zeitraum oder ...



  • @GMgenia sagte in Von UML zu C++ (Analysemuster "Wechselnde Rollen"):

    Wie ich dieses Muster interpretiere sollte in der Klasse Besucher die Möglichkeit bestehen beliebig viele "Besucherrollen" anzulegen. Im Beispiel sind es zwei: Gast und Künstler. Es könnten aber 5 oder 10 sein, oder eben beliebig viele.

    Ja, es können beliebig viele sein. Soweit stimmt das schon.

    Du musst auf jeden Fall zwischen den Besucherrollen Klassen und den Objekten dieser Klassen unterscheiden.

    Also ...
    Ein Besucher kann beliebig viele Veranstaltungen besuchen. z.B. kann es sein dass er nur eine Veranstaltung besucht, und dort Gast ist. Dann hätte dieses Besucher Objekt genau ein Besucherrollen-Objekt vom Typ Gast. Und keines vom Typ Künstler.

    Ein anderer Besucher besucht 3 Veranstaltungen und ist auf allen dreien Gast. Dieses Besucher Objekt hätte dann drei Besucherrollen-Objekte vom Typ Gast. Und keines vom Typ Künstler.

    Und wieder ein anderer besucht eine Veranstaltung als Gast und zwei weitere als Künstler. Der hätte dann dementsprechend ein Besucherrollen-Objekt vom Typ Gast und zwei vom Typ Künstler.

    Usw.

    Damit sollte jetzt auch klar sein, dass in dem Besucherrollen-Objekt noch irgend ein Attribut sein muss das uns sagt um welche Veranstaltung es sich handelt. Denn sonst können wir die Besucherrollen-Objekt ja nicht zuordnen. Also wir können sie dem Besucher zuordnen. Aber wir wissen nicht wo er als Künstler auftritt, wo er Gast ist und rein darf weil das Besucherrollen-Objekt die Information "hat Ticket gekauft = true" hat und wo er Gast ist aber nicht rein darf weil das Besucherrollen-Objekt die Information "hat Ticket gekauft = false" hat.

    Genau hier bin ich mir nicht sicher ob ich das Problem irgendwie falsch vestehe.

    Irgendwas verstehst du irgendwo falsch. Da bin ich mir fast sicher 🙂 Kann dir aber leider nicht sagen wo und was.



  • @hustbaer sagte in Von UML zu C++ (Analysemuster "Wechselnde Rollen"):

    Irgendwas verstehst du irgendwo falsch. Da bin ich mir fast sicher Kann dir aber leider nicht sagen wo und was.

    Jajjajajaja! 😄 😄

    Ok, ich versuche einfach mal weiter im Buch voranzukommen. Vielleicht klären sich die Fragen dann von allein... Ansonsten, hättest Du als Vorschlag ein gutes Buch das "UML zu C++" behandelt? Ich habe eins bestellt, das gut sein soll, zumindest nach den wenigen Kundenbewertungen die ich dazu finden konnte: "C++, UML und Design Patterns (Deutsch) Gebundene Ausgabe – 1. Juli 2005, von Helmut Herold". Vielleicht kennst Du ein anderes gutes Buch zum Thema?



  • @hustbaer sagte in Von UML zu C++ (Analysemuster "Wechselnde Rollen"):

    Es ist eine mögliche Umsetzung der 1:N Beziehung. Ob es die angebrachte Umsetzung ist lässt sich nur anhand des Musters nicht beantworten. Dazu muss man mehr Dinge darüber wissen was das Programm alles machen soll.

    Ok, verstehe!



  • Hallo GMgenia,
    was mit bei dem Ausschnitt von "Muster 7: Wechselnde Rollen" (und auch den anderen) auffällt, ist die Datenlastigkeit der Beispiele. Ich verstehe @hustbaer in seiner einleitenden Worten sofort, dass er so stark auf "Datenbank" reflektierte.

    Ich persönlich gehe die Analyse selten von den festen Attributen an, sondern betrachte, was soll mir ein Objekt einer Klasse alles liefern. Wo die Daten herkommen, ist mir erst im Design wichtig (da mach ich mir auch erst Gedanken, welchen Typ diese haben sollen).

    Was dem Muster meiner Ansicht nach fehlt, ist die gewünschte Funktionalität. Welcher Service wird von welcher Klasse gewünscht?
    Polymorphie (durch Vererbung) ist ein wichtiger Bestandteil der objektorientierten Softwareentwicklung (lese gerne mal hier http://openbook.rheinwerk-verlag.de/oop/oop_kapitel_05_002.htm). Das vorliegende Muster hat aber nur Daten, wird aber ggf. erst durch Methoden sinnvoll einzusetzen sein.

    Nehmen wir an, wir brauchen eine Abfrage der Zutrittsberechtigung zu Objekten der noch fehlenden Klasse [Veranstaltung].

    Dazu könne man sich die Methode

    bool Besucher::hatZutrittsberechtigung( Veranstaltung & veranstaltung);
    

    ausdenken.

    Die Klasse [Besucherrolle] bekommt eine (ggf. pure) virtuale Methode mit evtl. gleichen Namen, z.B.

    bool Besucherrolle::hatZutrittsberechtigung( Veranstaltung & veranstaltung) = 0;
    

    die von den Objekten der Unterklassen, hier [Kuenstler] und [Gast] jeweils anders implementiert ist. Der Gast darf rein, wenn er ein Eintrittskarte für die Veranstaltung hat und der Künstler wenn er für die Veranstaltung gebucht ist.

    Eine anfragende Instanz braucht also die einzelnen Rollen des Besuchers nicht kennen. Wenn Du jetzt auf die Idee kommen solltest, eine zusätzliche Rolle zu definieren (z.B. eine fest angestellte Kraft die nicht gebucht ist und keine Eintrittskarte bracht), braucht die anfragende Instanz NICHT geändert werden, also casten fällt flach.

    Werden rollenspezifische Funktionalitäten benötigt, muss gecastet werden.

    Bei dem, was ich in dem Ausschnitt aus dem vorliegenden Buch sehe, lässt bei mir den Verdacht aufkommen, dass der/die Autoren*inen aus dem Datenbankbereich kommen. Vieles sieht für mich irgendwie nach Datenbankentwurf aus.

    Auf Deine Frage 1: Welchen Container Du nutzen sollst, kann ich nicht beantworten (vector, list map ???). Aber ich würde, wenn geht, immer intelligente Zeiger nutzen (keine *-Pointer) und einen Container auf [Besucherrollen], nicht auf die Unterklassen.

    Frage 2 ist schon beantwortet.

    Gruß Helmut



  • @GMgenia sagte in Von UML zu C++ (Analysemuster "Wechselnde Rollen"):

    Ansonsten, hättest Du als Vorschlag ein gutes Buch das "UML zu C++" behandelt? Ich habe eins bestellt, das gut sein soll, zumindest nach den wenigen Kundenbewertungen die ich dazu finden konnte: "C++, UML und Design Patterns (Deutsch) Gebundene Ausgabe – 1. Juli 2005, von Helmut Herold". Vielleicht kennst Du ein anderes gutes Buch zum Thema?

    Da kann ich dir nicht helfen denn ich kenne keins. Ich könnte dir nichtmal ein schlechtes empfehlen 🙂 Ich verwende UML so formal nicht. Die Analysemuster sind schon OK, denn es ist gut die ganzen üblichen Muster zu kennen. Wobei ich die Namen komisch finde, denn für mich sind das eher Muster wie man Daten organisiert. Trotzdem natürlich gut diese zu kennen. Was mir in den kurzen Abschnitten die ich in deinen Links gelesen habe aber fehlt ist eine ausführliche Beschreibung der Eigenschaften der Muster. Also

    • Was sind die "driving forces" die dazu führen dass man das Muster berücksichtigen sollte/wofür ist es gedacht?
    • Eine Abstrakte Beschreibung was es macht (konkrete Beispiele die natürlich auch wichtig sind waren vorhanden).
    • Was kann man damit machen?
    • Was kann man nicht damit machen?
    • Was sind die Vorteile?
    • Was sind die Nachteile?
    • Was sind verwandte Muster für ähnliche Situationen und was sind die unterschiede zu diesen verwandten Mustern?

    Ein gutes Buch zum Thema Design Patterns wäre das sog. "Gang of Four" Buch.



  • @hustbaer Hallo! Ja, ich merke, dass ich noch einen schweren Einblick zu diesem Thema habe. Die Fragen die Du stellt, stelle ich mir auch, aber die sind in meinem Kopf viel "flausiger" 😌

    Ich werde dann mal in diese Buch reinschauen, das wohl die "Mutter" aller Bücher zu UML wäre. Vielen Danke für Deine guten Anregungen! Die haben mir sehr geholfen etwas strukturierter zu denken.



  • @Helmut-Jakoby sagte in Von UML zu C++ (Analysemuster "Wechselnde Rollen"):

    Eine anfragende Instanz braucht also die einzelnen Rollen des Besuchers nicht kennen. Wenn Du jetzt auf die Idee kommen solltest, eine zusätzliche Rolle zu definieren (z.B. eine fest angestellte Kraft die nicht gebucht ist und keine Eintrittskarte bracht), braucht die anfragende Instanz NICHT geändert werden, also casten fällt flach.

    Oh, vielen Dank für diese ausführliche und sehr gute Antwort. Vor allem die Aussage zum Casten, der nicht gebraucht würde, gibt mir ein besseres Verständnis was hinter diesem Modell zu verstehen ist!

    Vielen Dank!



  • @GMgenia
    Vielleicht könnte das für dich interessant sein: https://www.researchgate.net/publication/307449818_GoF_Design_Patterns_with_examples_using_Java_and_UML
    Keine Ahnung ob das gut ist, aber es behandelt wohl die selben Patterns die auch in "dem" GoF Buch behandelt werden.



  • @hustbaer sagte in Von UML zu C++ (Analysemuster "Wechselnde Rollen"):

    @GMgenia
    Vielleicht könnte das für dich interessant sein: https://www.researchgate.net/publication/307449818_GoF_Design_Patterns_with_examples_using_Java_and_UML
    Keine Ahnung ob das gut ist, aber es behandelt wohl die selben Patterns die auch in "dem" GoF Buch behandelt werden.

    Oh! Das sieht schon sehr gut aus. Zwar in Java, aber ich denke mit etwas Kopf zerbrechen kommt man dahinter! Super! Vielen Dank!


Anmelden zum Antworten