## Verbundobjekte in der Objekteorientierten Analyse (Kapitel 32)


*  Können Sie bitte noch einmal kurz erklären, warum ein Mixin Zugriff auf das Hauptobjekt hat? Ich dachte immer, das wäre nur ein kleines Unterobjekt. Wie schafft es, auf Attribute vom Oberobjekt zuzugreifen?
   *  In UML herrscht zwischen Hauptobjekt und Mixin oft ein gerichteter Pfeil. Es ist richtig, dass bei Richtung kein rückwärts gewandter Zugriff vom Mixin zum Hauptobjekt möglich ist. Die Entwurfsmuster Bridge verwendet ebenfalls einen gerichteten Pfeil.
   *  Falls man Ports an Klassen als Mixins beigibt, also Komponenten spezifiziert, sollte man
   
      *  *ungerichtete* Pfeile vom Hauptobjekt zum Port verwenden, wenn man Informationen aus dem Hauptobjekt (oder aus anderen Mixins) holen will
      *  *gerichtete* Pfeile verwenden, wenn man *keine* Informationen aus dem Hauptobjekt holen will.
*  Verbundprojekte sind für mich soweit gut verständlich, wenn es um UML geht. Aber was ist, wenn man sich Java anschaut? 

   *  Java kann nur "Referenzen", keine Teile, keine Rollen, keine Mixins. Uff. Andere Programmiersprachen können das, z.B. ENBF für Grammatiken, Ruby, etc. 
*  Wenn ich eine Klasse Person habe und eine Unterklasse Geburtsurkunde als Mixin, wie würde dann dieses Mixin auf z.B. das Attribut "Liebingseis" von Person zugreifen?

   *  Das muss man entwerfen, dh. es liegt an der Richtung der Pfeile zwischen Kernobjekt und Mixins. Bei Richtung ist kein Rückwärtsgreifen auf das Kernobjekt (und die anderen Mixins) möglich; bei ungerichteten Pfeilen schon. 
   *  Also muss man sich entscheiden: Will man Richtung oder nicht?
 *  Hallo, wenn ich eine Komponente habe (also ein Mixin als Schnittstelle), kann man dann als Client über diese Schnittstelle nur Informationen über jenes Mixin (was ja als Schnittstelle dient) abfragen oder auch über die Klasse, zu dem das Mixin gehört?

    * Ja, beides. Es hängt an der Richtung der Aggregationspfeile, s.o. 
*  Auf Folie 75, Kapitel 32 verstehe ich noch nicht ganz, warum man einen Decorator verwendet, um Listen darzustellen. Collections funktionieren doch auch?

   *  Listen können prinzipiell mit Collections ODER Decorator implementiert werden. Im ersteren Falle kann man verschiedene Implementierungen von Listen polymorph variieren, im zweiten Fall ("object recursion") nicht. 
*  Könnten Sie den Unterschied zwischen "Multi-Role Bridge" und "Multi-Part Bridge" erklären?

   *  Der ist nur marginal. Role Bridge drückt eine temporär vorhandene Rollenbeziehung aus; Part Bridge eine Teilebeziehung (die permanent sein kann, auch rigide)
*  In Kapitel  32 haben Sie gesagt, dass man nicht-ridgide Typen durch Partizip Präsenz Aktiv beschrieben werden können. Wie genau funktioniert das z.B. bei Vater?

   *  Ja, es ging mir mehr um die *temporäre* Gültigkeit des Prädikats "hat ein Kind gezeugt". Bei Rollen und anderen nicht-rigiden Typen muss das Prädikat temporär gültig sein, nicht dauerhaft (sonst wär's ein rigider Typ).
*  Könnte man das dann nicht auch bei Menschen machen. Also: "geboren sein" oder "Mensch seiend", aber Mensch ist ja ridige.

   *  Ja, aber dieses Prädikat ist dauerhaft, also ist der Typ rigide
*  Keine Frage zur Vorlesung, aber können Sie ein wenig über das Praktikum im WS erzählen? Was muss man da machen, wie läuft das ab, Gruppen, usw.?

   *  Gruppen a 6-7 Personen; neue Probleme wie Abstimmung, Kommunikation, gemeinsame Meilensteine, etc. In Firmen wird immer gruppenorientiert gearbeitet.
   *  Gruppenorientierter SCRUM-Prozess mit Sprints, Anforderungsmodellierung, Design, Test etc. 
   *  7 Meilensteine, Abschluss durch Präsentation. Interne Aufgaben zu webbasierten Informationssystemen wie "Videoshop", "Apotheke"
   *  Benutzung des Client-Server-Web-Frameworks Spring. Achtung: Sie brauchen ALLE Inhalte der Vorlesung, um Spring zu verstehen. Dann aber gibt es Ihnen eine tolle Hilfe zur Implementierung Ihrer Aufgabe.