Protokoll der Prüfung "Objektorientiertes Softwareengineering" (1794)

Prüfer: Prof. Six
Datum: 18.3.2002
Beisitzer: Gab's auch, Name ist mal wieder vor der Prüfung an mir vorbeigegangen
Dauer: ca. 30 min.

Die Prüfung war insofern anders als meine anderen Prüfungen an der FernUni, als daß Herr. Prof. Six relativ wenige konkrete Fragen zum Kurs gestellt hat, sondern die Prüfung mehr als Diskussion zu Themen aus dem Kurs lief. Insofern kriege ich auch keine Liste von Fragen mehr zusammen, sondern nur eine der angesprochenen Themen.
Vor der Prüfung fragte Herr Six kurz, ob ich berufstätig sei (ja) und ob ich denn mit dem Themen im Kurs auch zu tun habe (was ich dann etwas widerwillig auch bejahte, schließlich verdiene ich meine Brötchen derzeit mit Java- und C++-Programmierung).
Einstieg war, daß er sagte, es gebe ja im Kurs verschiedene Modelle, ich solle doch mit einem anfangen und es erläutern.
Ich habe dann mit dem Anwendungsfalldiagramm angefangen und erläutert, was ein Anwendungsfall so ist und wofür er da ist. Für die Definition habe ich den Satz mit dem "erkennbaren Fortschritt für einen Benutzer" gebracht, der wohl in der nächsten Version anders formuliert sein wird. Die Granularität eines Anwendungsfalls ist ziemlich grob, nicht zu fein gliedern.
Er wollte noch hören, wie Anwendungsfälle beschrieben wird und ob die verschiedenen flows verschiedene Vor- und Nachbedingungen haben können. Ergebnis: Sie können einzelne Nachbedingungen haben, wichtig ist aber wohl, daß die "richtigen" Vor- und Nachbedingungen vor bzw. nach allen verschiedenen Abläufen gelten müssen.
Welche Beziehungen gibt es zwischen Anwendungsfällen? Extend- und Include-Beziehung erklärt und Beispiele nach Kurs gebracht, dann noch erwähnt, daß es die Möglichkeit zur Generalisierungsbeziehung gibt. Er hat dann gefragt, ob das so etwas wie die Include-Beziehung sei, da ja beide Gemeinsamkeiten aus Anwendungsfällen extrahieren. Habe ich verneint, da bei der Include-Beziehug i. d. R. keine Substituierbarkeit gilt, er fand aber wohl doch, daß da zumindest eine Ähnlichkeit sei. Dann fragte Hr. Six, wer so alles mit den Diagrammen arbeite. Antwort: Erstellung durch Analytiker, Anwender müssen diese aber verstehen und damit wird sichergestellt, daß die Analytiker tatsächlich richtig verstanden hat, was er so analysiert hat. Deshalb sind Generalisierungsbeziehungen hier wohl eher unglücklich. Er fragte dann noch, was mit der oft im Kurstext zitierten "Problemadäquatheit" gemeint sei. Ich sagte, daß zu jedem Modellkonstrukt ein Pendant in der Problemwelt existieren müsse, d. h. für Anwendungsfälle, zu jedem ein reales Szenario. Für generalisierte Anwendungsfälle wird's da schwierig.
Themenwechsel zu Klassendiagrammen: Wofür eingesetzt? In allen Phasen, in der Analyse als Domänenklassenmodell, später im Entwurf mit zunehmender Bedeutung, da sie im Grobentwurf auch die Anwendungsfallmodelle ablösen.
Wie beschreibt man Klassen? Name, Attribute, Methoden. Er hat noch nach dem Unterschied von Methoden und Operationen gefragt, habe ich prompt verwechselt. Ist aber wohl ein Randthema.
In der textuellen Beschreibung: Name, Kommentar, Invariante, Verantwortlichkeit, Attribute, Methoden mit Vor- und Nachbedingungen. Dann fragte er mich noch, "ob ich tatsächlich daran glaube" (oder so ähnlich). Ich antwortete mit einem klaren "bedingt". Darauf erzählte er, daß die UML ja sehr reichhaltig sei und für viele Situationen das passende bereit halte, wir uns deshalb entsprechend aus diesem Angebot bedienen könnten, es ihn aber schon sehr erstaunte, falls jemand tatsächlich für alle Klassen all diese Elemente detailliert durchzieht.
Was für Assoziationen gibt es? Kardinalitäten, Navigierbarkeit und Rollen erläutert. Kann es sein, daß eine Klasse eine Assoziation zu einer anderen hat, aber nie eine Methode der anderen Klasse aufruft? Antwort meinerseits:Kann schon, wäre aber sehr ungewöhnlich und ein starkes Indiz dafür, daß die Assoziation überflüssig ist.
Generalisierung vs. Vererbung: Hier entwickelte sich das ganze noch mehr zur Diskussion, angesprochen:
Zunächst wolle ich hier Substituierbarkeit und Konformität erläutern, daß hat er dann aber abgebrochen.
Wofür Vererbung ? => Code-Wiederverwendung
Vorteil Generalisierung: Bei Entwurf mit Verträgen können diese auf die Spezialisierungen ausgedehnt werden.
Wo können nach Überschreiben einer Methode Fehler auftreten? In der Methode selbst und in anderen Methoden, die die überschriebene dynamisch binden (was ggf. nicht von außen sichtbar ist).
Hilft es, Überschreiben zu verbieten? Nicht wirklich, da es möglich ist, nicht-konforme Subtypen zu bilden, ohne eine Methode zu überschreiben.

Frage an den Beisitzer, wann wir eigentlich angefangen hatten, Ende der Prüfung.

Gesamteindruck: Gut, wobei ich den Prüfungsstil ungewöhnlich finde.  Ich hatte zu Anfang etwas die Befürchtung, daß ich zuwenig zu den einzelnen Themen sage, und habe dann nicht nur auf Fragen gewartet, sondern mich etwas ins Gespräch gedrängelt.
Wichtig ist wohl einmal ein solides Basiswissen über die Modelle zur funktionalen, strukturellen und Verhaltensmodellierung, zum anderen der Überblick darüber, wie diese Modelle in den Arbeitsschritten Analyse, Grob- und Feinentwurf zusammenhängen. Darum nicht nur alle Kurseinheiten für sich lernen, sondern auch im Zusammenhang.