- Q: Es geht um die Facade- und UseCase-Controller. Kurz zu meinen Überlegungen: Systemoperationen haben eine gemeinsame Schnittstelle (Facade-Controller), dieser Facade-Controller leitet die Systemoperationen weiter zu den UseCases, wobei dort der UseCase-Controller für das weitere Vorgehen verantwortlich ist. Sind meine Überlegungen korrekt?
- A: Nein: Ein (Application-)Controller ist das erste Objekt jenseits der UI-Schicht, welches eine Systemoperation empfängt und koordiniert (Larman). Sie wollen nun zwei Controller hintereinander schalten, das widerspricht dieser Definition. Normalerweise sind Facade- und Use Case Controller Alternativen. Ihr Vorschlag verwendet einen Facade-Controller, welcher nur als Dispatcher funktioniert, also gar kein Controller gemäss obiger Definition mehr ist. Natürlich könnte man ein solches Design realisieren, ist aber wohl meist unnötig kompliziert. H. Rudin 12.1.13
- Q: Bei Übung03 muss ein Kinoreservationssystem modelliert werden. Ist es notwendig, dass es eine Klasse SitzplatzBelegung gibt? Sie wird im Text nicht erwähnt. Die Reservation könnte auf den konkreten Sitz & Vorstellung gelten und die Tickets vielleicht in der Reservation untergebracht werden (so meine Lösung).
- A: Das geht schon, aber dann steht da noch "Sitzplätze können natürlich auch an der Abendkasse verkauft werden. Dies muss im Online-Reservationssystem natürlich nach- geführt werden." Also braucht es dann noch so etwas wie ein "Sitzplatzverkauf", der mit Sitzplatz und Vorführung assoziert ist. Die SitzplatzBelegung in der Musterlösung umfasst sowohl diesen "Sitzplatzverkauf" als auch die Reservationsinformation, die Sie durch die Assoziationen auf Sitzplatz und Vorstellung gelöst haben. H. Rudin 10.1.13
- Q: Wie genau müssen wir dies oder das beherrschen?
- A: Bezüglich Prüfungsinhalt gelten die Angaben der Prüfungsinformation. Ich mache keine genaueren Angaben, sonst habe ich jede Menge Mails zu beantworten zum Thema "Kommt dies, kommt das, wie genau müssen wir, ....?" Ich beantworte aber gerne Ihre inhaltlichen Fragen. H. Rudin 10.1.13
- Q: Ist das Schreiben mit Bleistift an der SE1-Prüfung erlaubt? Dies wäre vor allem beim Zeichnen von Diagrammen von Vorteil.
- A: Ja, das ist erlaubt und für die Diagramme würde ich das auch empfehlen. H. Rudin 10.1.13
- Q: Können Sie eine Übersicht des RUP geben?
- A: Dazu habe ich eine Zusammenfassung 02-Prozesse.pdf auf dem Skripteserver im Directory Summaries erstellt. Larman hat auf der Innenseite des Buchdeckels eine Zusammenstellung, welche Workproducts in welcher Phase erstellt werden. H. Rudin 4.1.13
- Q: Antwort auf die Frage „Wenn man Features/Tickets eingibt, taucht die Frage auf: wo sind jetzt die Use Cases? Was ist der Bezug von Features zu Use Cases? Versuchen Sie bitte, diese Frage zu beantworten, indem Sie die Frage in der Gruppe diskutieren.“ Aus Ü20 – Redmine.
- A: Redmine macht keine Vorschriften wie Use Cases in Tickets zu transformieren sind. Man kann übergeordnete Tickets für Use Cases verwenden und dann Subtickets für alle Features/Tasks verwenden, die diesen Use Case betreffen. Es stellt sich allerdings die Frage, ob sich der Aufwand lohnt, diesen Zusammenhang abzubilden und vor allem nachzuführen. H. Rudin 4.1.13
- Q: Verständnisfragen bezüglich Domainmodellen: Gehören bei einer n:n-Assoziation die assoziativen Klassen ebenfalls in das Domainmodell?
- A: Hm, das Domainmodell enthält alle für das Problem relevanten Informationen des Problembereichs. Gibt es relevante Informationen, die zu einer n:n Assoziation gehören, dann und nur dann sollen diese im Domainmodell modelliert werden. Wenn es zwischen zwei Instanzen der durch die Assoziation verbundenen Klassen nur eine Instanz der Assoziation gibt (Link), dann kann diese Information in einer Assoziationsklasse modelliert werden (siehe 03-3-OOA-Domainmodellierung.pdf Slide 25). Sind mehrere Links zwischen Instanzen der verbundenen Klassen möglich, ist die Verwendung einer Assoziationsklasse falsch (siehe 03-3-OOA-Domainmodellierung.pdf Slide 26). In diesem Fall muss die Assoziation durch eine Zwischenklasse aufgebrochen werden, welche die relevante Information enthält. Das ist also eine Feinheit von UML. Ich verwende daher in Regel keine Assoziationsklassen in der Domainmodellierung sondern immer eine Zwischenklasse. Wenn Sie aber Assoziationsklassen verwenden, sollten Sie dies natürlich UML-konform tun. H. Rudin, 4.1.13
- Q: Verständnisfragen bezüglich Domainmodellen: Ist diese Formulierung korrekt: Pure data values (auch: value objects) sind Datentypen, bei welchen die Identität keine Rolle spielt, es geht lediglich um den Wertevergleich. z.B. Adresse, Zeit, Datum
- A: Ja, das ist korrekt. Damit sind Value Objects auch keine mit anderen Domainklassen "gleichberechtigten" Domainklassen, sondern sollten eher als Datentypen von Attributen von Domainklassen verwendet werden. H. Rudin, 4.1.13
Für die Benützung des Wikis siehe
WelcomeVisitors.
Ein RSS-Feed ist über http:rss.cgi erreichbar (bzw. wird im Firefox rechts unten zum Bookmarken angeboten.)
