Sie befinden sich hier: Termine » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Lehrstuhl 2 » Allgemeines   (Übersicht)

Inhaltsverzeichnis

Allgemeines

Gehalten wurd die Vorlesung von Ralf Ellner. Ich habe mich auf die Prüfung vorbereitet, indem ich alle Folien durchgegangen bin und mir Grundsätzliches zu UML (Was ist es, für was wird es verwendet, welche Ziele werden damit verfolgt), zu den verschiedenen Diagrammen und zum UML Metamodell herausgeschrieben hab. Diese Zusammenfassung hab ich dann mehr oder weniger auswendig gelernt und das Ergebnis kann ich auf jeden Fall weiter empfehlen. Dauer hierfür: ca. eine Woche.

Inhalt

Die erste Frage war, wie zu erwarten, was ist UML: UML steht für Unified Modeling Language und ist eine standardisierte, universelle, semi-formale Modellierungsnotation für Softwaresysteme. Sie wird zur Visualisierung, Sepzifikation, Entwicklung und Dokumentation verwendet.Hier darf man ruhig etwas ausführlicher beschreiben, wann im Entwicklungsprozess UML verwendet wird und auch schon einige Diagrammtypen nennen.

Dann ging es weiter mit der Frage, wie würden Sie ein Entwicklungsprojekt, bei dem die Anforderungen definiert werden müssen, beginnen. Hier lautet die Antwort: mit Use Case Diagrammen, die aus einer Systemgrenze, verschiedenen Anwendern und Fremdsystemen und den Anwendungsfällen selbst bestehen. Auch hier sind weitere Ausführungen sicher nicht verkehrt, siehe Skript

Ich habe dann ein Use Case Diagramm vorgelegt bekommen, das einen Bankautomat gezeigt hat. Das findet sich auch so 1:1 im Skript. Das sollte ich „lesen“ und erklären was hier dargestellt ist. Wichtig war den Prüfern: «exclude» in Kombination mit extensionPoint in einem Use Case bedeutet, der verknüpfte Anwendungsfall wird optional durchgeführt, «include» bedeutet, der verknüpfte Anwendungsfall wird immer durchgeführt.

Nächste Frage: wie geht es nach dem Use Case Diagramm weiter? Die Antwort, die sie hier hören wollten war mit Klassendiagrammen. Es war zwar nicht explizit gefragt, aber ich denke hier könnte man auch kurz erwähnen, wie man geeignete Klassenkandidaten findet (Substantivmethode, CRC Karten).

Dann bekam ich auch ein Klassendiagramm vorgelegt, dass ich lesen und analysieren sollte, da es einige Fehler enthalten hatte. Um einige zu nennen: ein Paket hat von einer Klasse geerbt, der Paketname lautete „Meier:Person“, die Klasse Adresse hat von der Klasse Person geerbt. Hierfür sollte man auf jeden Fall wissen, was Multiplizitäten sind, was Rollen sind, was Stereotypen sind. Woran ich etwas gehangen war, was sich auch im Nachhinein als erweiterte Frage herausstellte, was bedeutet «DataType»? Die richtige Antwort hierfür ist: «DataType» im Klassenname bezeichnet eine Klasse die einen Wert verwaltet. Dieser Wert wird entweder gesetzt oder es wird nur lesend auf ihn zugegriffen. Eine solche Klasse sollte möglichst schlank gehalten werden und keinen eigenen Zustand besitzen. Typisches Beispiel hierfür: String, Integer.

Aus den syntaktischen Fehlern habe ich dann selbst zum UML Metamodell überführt, aber das war wohl auch so von den Prüfern beabsichtigt. Das sollte ich kurz erklären und dann wurden einige Fragen dazu gestellt: wie werden Klassen im UML Metamodell repräsentiert? mit der Klasse „Class“. Wie werden Vererbungsbeziehungen im UML Metamodell dargestellt? mit der Klasse „Generalization“. Den Zusammenhang zwischen beiden sollte ich kurz als Klassendiagramm sizzieren. Das waren eben die beiden Klassen mit einem Abhängigkeitspfeil von Generalization zu Class. Die Muliplizitäten an Class-Seite waren 2..* und an der Seite von Generalization war 0…*.

Dann kamen noch einige Fragen zu Constraints und wie diese in ein Use Case Diagramm eingebaut werden können. Es gibt 4 Möglichkeiten ein Constraint zu formulieren (immer in geschweiften Klammern): in Prosa, mit Prädikatenlogik, in Pseudocode und mit der Object Constraint Language. Hier wurde weiter bei der Object Contraint Language gefragt: Es handelt sich hierbei um eine Erweiterung von UML mit eigenen Datentypen und logischen Ausdrücken. Es ist eine Constraint-Sprache, die im Vergleich zu Java keine Variablen schreiben oder verändern kann. Aus ihr kann ein geeigneter Codeconverter Sourcecode in der Zielsprache generieren.

Zusammenfassung

In Summe war es eine recht lockere Atmospähre, was wohl auch daran lag, dass die Antworten so kamen, wie die Prüfer es erwartet hatten und dass es einige lustige Versprecher meinerseits gab.

Mein Fazit: wer den Stoff lernt, was mit den Folien sehr gut funktioniert, bekommt hier recht einfach eine gute Note.