# Fragen zu Vorlesungsfoliensatz 41:

1) Was ist ein Verteilungsdiagramm?
Siehe Folie 30/31 Folienset 41 für Erklärung und Bespiele. Zeigt Verteilung der Teilsysteme z.B. auf Servern/Komponenten an. Hinweis für später: Bei nicht-standardisierten Diagrammen sollte eine Legende dazu gelegt werden.

2) Welche architektonische Sichten auf ein System gibt es?
Siehe Folie 57 Folienset 41: Hofmeister/Soni/Nord Perspektivenmodell

3) Inwiefern besteht das Kontextmodell aus hierarchischen Komponenten?
Kontextmodell beschreibt das System als Komponente mit seinen Schnittstellen nach außen.
Es kann natürlich weitere Komponenten enthalten (Hierarchie). Dies wird z.B. durch die Top-Level-Architektur modelliert.

4) Wann muss man die Administrative Schicht ändern?(wozu die Variabilität)
Administrative Schicht: sichert die Qualität des Systems (Folie 25, Folienset 41)
Variabilität Bespiele:
- verschiedene Qualitätsansprüche von Kunden
- Developer-Umgebung vs. Kunde-Umgebung

5) Können Sie noch einmal ein größeres Bild der VL geben und die aktuelle VL darin einordnen?
  1) VL orientiert sich mit am Softwareentwicklungszyklus. Heutige Vorlesung sind dem Entwurf, konkrete Entwurf "im Großen" zuzuordnen.

6) Was war noch einmal der Quasar-Architekturstil?
  * Quasar definiert Stereotypen, mit denen man Programmeinheiten(Methoden, Klassen, Pakete, Module) nach Wiederverwendbarkeit klassifizieren kann  ("Blutgruppen"). Die Blutgruppen kennzeichnen die Zwecke einer Programmeinheit.
  * 0- und T-Blutgruppen sind gut wiederverwendbar, da nicht anwendungsspezifisch. 
  * A-Blutgruppe ist nicht gut wiederverwendbar, da sie domänenspezifisch ist.
  * AT gar nicht gut, da man die Technik-Teile auch nicht trennen kann. 
  * Quasar ist also ein Profil, das "Wiederverwendbarkeit" beschreibt.

7) Können sie bitte nochmal kurz das Entwurfsmuster Command erklären?
   * Command kommt in Kap. 25.2 vor. Es bildet ein "reifizierte Aktion" ab, d.h. anstatt dass eine Aktion mit einer Methode durchgeführt wird, wird ein Objekt gebildet, das mit "execute()" die Aktion durchführen kann, mit "undo()" sie zurücknehmen und "redo()" sie wiederholen kann. 
   * Command-Objekte können in Listen verwaltet werden und vom Muster Interpreter genutzt werden. Diese Listen können auch persistiert werden, da sie Objekte sind. 
   * Commands stecken hinter allen interaktiven Oberflächen (Knöpfe, Menüeinträge, etc.)
8) Beim Wiederholen bin ich nochmal auf das Muster TemplateMethod zurückgekommen und habe mich gefragt, ob alle abstrakte Klassen mit abstrakten Methoden, die von Unterklassen implementiert werden, diesem Muster entsprechen oder ob das Muster noch spezifischer ist?
   * TemplateMethod enthält eine konkrete Methode, die die Schablone eines Algorithmusses darstellt, der für alle Unterklassen gleich ist, aber durch den Aufruf von "Hook-Methoden" parametrisiert wird, die in der TemplateMethod-Klasse abstrakt sind und durch die Unterklassen ausgefüllt werden müssen. 
   * Dadurch gibt es einen fixen und einen variablen Teil des Algorithmusses. 
   * Damit ist das Muster etwas spezieller als allg. Polymorphie. 
9) Sie haben ja verschiedene Möglichkeiten für die Implementierung für "plays-a" vorgestellt. Gibt es da Vorteile bzw. Nachteile bei einigen Varianten? Wonach entscheidet man sich für eine Variante?
   * Dazu mehr in "Design Patterns and Frameworks". 
   * Kurz gesagt gibt es 3 Alternativen
     * Merge von Rollen in die Kernobjekte mit Vererbung. Das erzeugt eine statische Bindung, sodass man Rollen nicht mehr austauschen kann, ist aber i.d.R. laufzeiteffizient.
     * Merge von Rollen in die Relationen.  Das erzeugt eine statische Bindung, bei der "Assoziationsklassen" und -objekte entstehen. Wenn man also viel mit Relationen macht, kann das günstig sein.
     * Separate Rollenobjekte mit z.B. Role-Multi-Bridge ("maximaler Splitt"): Das ist sehr flexibel, weil die Rollenobjekte ausgetauscht werden können, aber kann laufzeitineffizient sein. 
     * Mehr Muster dazu in "Design Patterns and Frameworks".