Vorlesung

Übungen

Informationen

zur Startseite

Modul Informatik II

Frequently Asked Questions

  • Wann findet die Prüfungseinsicht statt?

    Nachdem die Noten bekannt gegebenen wurden, wird ein gemeinsamer Termin für die Prfüngseinsicht festgelegt. Bitte melden sich mit Ihrem Namen, Ihrer Matrikelnummer und Ihrer E-Mail-Adresse beim Vorlesungsassistenten für die Prüfungseinsicht an. Sie werden per E-Mail über den Termin informiert.

  • Ich kann kein Java - kann ich trotzdem Info2 hören und die Prüfung schreiben?

    Es gibt Studenten, die keine Java-Kenntnisse in Info2 mitbringen. Darauf nehmen wir im Allgemeinen in der Prüfung Rücksicht. Wir bitten trotzdem im Einzelfall um eine kurze Rücksprache. In der Vorlesung verwenden wir aber Java-Beispiele, um die Umsetzung von objektorientierten Konzepten in einer Programmiersprache zu veranschaulichen. Diese sind nicht zu kompliziert und mit geringem Aufwand verständlich.

  • Worauf wird in der Prüfung Wert gelegt?

    Es geht in der Prüfung mehr darum, das System, das in der Aufgabenstellung beschrieben ist, genau zu verstehen und es in den geforderten Modellen so zu modellieren, dass es auch wie in der Aufgabenstellung beschrieben funktioniert. Deshalb wird z.B. nicht erwartet, bei einer Operation alle Parameter anzugeben, sondern nur, wenn diese aus der Aufgabenstellung offensichtlich sind.

  • Muss ich für die Prüfung die UML-Notation auswendig lernen?

    Gute UML-Kenntnisse sind für die Prüfung sicher sinnvoll, um Diagramme korrekt zeichnen zu können. Es ist aber nicht notwendig, jedes Detail der UML auswendig zu kennen. Viel wichtiger ist das Verständnis der Vorgehensweise bei objektorientierter Analyse und Design, ohne das objektorientierte Softwaresysteme nicht sinnvoll entwickelt werden können.

  • Darf man in der Prüfung ein Notebook verwenden?

    Nein, programmierbare elektronische Hilfsmittel, also auch Notebooks, sind nicht erlaubt. Bitte lassen Sie auch ihre Handys zu Hause.

  • Sind UML und OOAD dasselbe?

    Die objektorientierte Analyse und Design (OOAD) ist eine Methode zur systematischen Vorgehensweise bei der objektorientierter Entwicklung von Softwaresystemen. Sie besteht aus objektorientierten Konzepten (z.B. Klasse), einer methodischen Vorgehensweise für Analyse und Entwurf und letztlich einer Notation für die Darstellung der objektorientierten Modelle. Eine solche Notation ist die UML. Mit ihr kann man die objektorientierten Konzepte graphisch ausdrücken. Die UML hat sich im Laufe der 90er Jahre aus verschiedenen Notationen entwickelt und wird heute fast ausschließlich verwendet.

  • Ich bin mir nicht immer ganz sicher, wann etwas zur Analyse und wann zum Entwurf gehört. Ist es bei der Prüfung ein Fehler wenn man z.B. die Datentypen bei Attributen in der Analyse dazuschreibt und diese nicht dahin gehören?

    In der Prüfung schreibe ich normalerweise dazu, was z.B. im Klassendiagramm alles angegeben werden soll. Wenn dann noch Fragen sind, kann man die auch in der Prüfung jederzeit stellen. Wer Angaben macht, die nicht gefordert sind, wird natürlich nicht bestraft - falls die Angaben richtig sind. Analyse und Entwurf sind nicht immer ganz klar zu trennen, das ist richtig. Es gibt aber ein paar Dinge, die man schon unterscheiden kann. Z.B. Sequenzdiagramme. Sequenzdiagramme, die im Entwurf erstellt werden, sind mehr an der Implementierung orientiert, d.h. sie sollen Abläufe in den Programme beschreiben (siehe Übung Acht). Deshalb muss dann auch immer die Rückgabe des Kontrollflusses nach Ende einer Aktivität eingezeichnet und richtigt geschachtelt werden. Dies entspricht dann genau dem Verhalten des Programmes beim Methodenaufruf. In den meisten Übungen und allen bisherigen Prüfungen haben wir uns allerdings mit Sequenzdiagrammen in der Analyse beschäftigt. Da ist das Ziel, die Abläufe im System erstmal aus Sicht der Problembeschreibung darzustellen. Zwar soll versucht werden, den Austausch der Nachrichten zwischen den Klassen (und evtl. dem Anwender) möglichst genau darzustellen, aber es ist nicht unbedingt notwendig, Aufrufe und Rückgabe korrekt zu schachteln (meist braucht man Rückgabe gar nicht). Di e Abläufe im System sollen eben aus Analysesicht und nicht aus Implementierungssicht dargestellt werden. Was dabei trotzdem wichtig ist, ist z.B. dass Namen von Botschaften im Sequenzdiagramm den Namen der Operationen der entsprechenden Klasse im Klassendiagramm entsprechen. Solche Hinweise gebe ich aber auch in der Prüfung.

  • Warum werden die Akteure eines Systems manchmal als Klassen modelliert (Prüfung F02) und manchmal nicht (Prüfung F03)?

    Akteure sind immer Benutzer des Systems. Manchmal ist es für das System wichtig, Informationen über diese Benutzer zu besitzen (z.B. in einer Bibliothek müssen die Daten der Kunden gespeichert werden) und manchmal völlig unwichtig. Z.B. bei einem Fahrkartenautomat oder einem Drehkreuz ist völlig bedeutungslos, den Benutzer zu kennen. Deshalb ist es dann auch sinnlos, Benutzer als Klassen zu modellieren. Es ist sehr wichtig, diesen Unterschied zu verstehen und in der Aufgabenstellung zu erkennen, ob ein System etwas über seine Akteure wissen muss.

  • Wann und wie benutze ich bei Anwendungsfällen uses/include bzw. extends?

    Uses gibt es in der UML seit 1.4 nicht mehr und wurde durch include ersetzt. include wird verwendet, wenn Teile eines Anwendungsfalles extrahiert werden, extends wird verwendet, wenn ein Anwendungsfall unter bestimmten Umständen durch einen anderen erweitert wird.

  • Ich kann nie unterscheiden, was bei der Anwendungsfallspezifikationstabelle zu Alternativen und was zu Erweiterungen gehört. Gibt es da irgendwelche Richtlinien oder muss man das meistens intuitiv entscheiden?

    Grundsätzlich können Sie sich folgendes Unterscheidungskriterium überlegen: Werden zusätzliche Schritte im Ablauf des AWF eingefügt und der Rest bleibt unverändert -> Erweiterung. Werden Schritte anstatt anderer Schritte durchgeführt -> Alternative (siehe Vorlesungsskript Kap. 4.1)

  • Warum kann man bei partiellen Anwendungsfällen als Vorbedingung, auslösendes Ereignis und Akteur nicht den Über-Anwendungsfall eintragen?

    Weil es häufig auch mehrere andere Anwendungsfälle gibt, in die ein partieller Anwendungsfall mit <> eingeschlossen ist. Welchen nehmen Sie dann? Generell sind partielle Anw.fälle ja nichts anderes aus das Herauslösen eines bestimmten Teils aus einem oder mehreren Anwendungsfällen. Das ist normalerweise ein Teil, der aus funktionaler Sicht relativ in sich geschlossen ist (z.B. Fahrpreis bezahlen). Deshalb ist es durchaus logisch, das er eine eigene Vorbedingung, auslösendes Ereignis und Akteur hat, auch wenn diese häufig mit dem Orginalanwendungsfall übereinstimmen.

  • Wird in Anwendungsfallspezifikationsschablonen das auslösende Ereignis nochmals als erster Schritt in der Beschreibung eingetragen oder nicht? Und wie sieht es mit der Überprüfung der Vorbedingungen aus?

    Meist macht es Sinn, das auslösende Ereignis zum besseren Verständnis des Ablaufes in der Beschreibung nochmal anzugeben. Überprüfung der Vorbedingung hängt von der Funktionalität ab, ist häufig nicht notwendig.

  • In der Prüfung vom Frühjahr 2002 wurden mit der include-Notation auch Vorbedingungen beschrieben. Wieso kann ich das so machen? Ich lagere ja nichts von einem Anwendungsfall aus?

    In der Prüfung war dies explizit in der Afg.stellung so gefordert (die Bedeutung des Stereotyps include wurde also abgewandelt). Ist das in der Afg.stellung nicht der Fall, halten Sie sich an die Verwendung von include und extends, die wir in Vorlesung und Übungen besprochen haben.

  • Beim Analysemuster Verbund ist eine Komposition zum Verzeichnis mit der Kardinalität 0..1 gegeben. Wie geht das? D.h. doch wenn kein Verzeichnis existiert, existiert die Datei dann evtl. noch? Allgemein versteh ich nicht so ganz wie es bei einer Komposition eine Kardinalität kleiner eins geben kann?

    Natürlich kann es Kardinalitäten kleiner eins geben. Sonst müsste ja jedes Objekt der Klasse Komponente beim Verbundmuster wieder Teil einer Komponente sein. Das gilt zumindest für das oberste Objekt nicht. Beim Beispiel Verzeichnis/Datei würde eine Kardinalität eins bedeuten, dass jedes Dateiobjekt - also auch jedes Verzeichnis - in einem anderen Verzeichnis enthalten sein müsste. Dass 0..1 heißt hier natürlich auch, dass es Dateien geben kann, die in keinem Verzeichnis untergebracht sind - was ja durchaus realistisch ist.

  • Genügt es in der Prüfung, bei CRC-Karten unter Kollaborationen nur die Klassen aufzuführen, welche die spezifizierte Klasse zur Erfüllung ihrer Aufgaben benötigt, oder müssen auch jene Klassen genannt werden, welche ihrerseits die beschriebene Klasse verwenden (also entgegen der offensichtlich notwendigen Navigierbarkeit der Assoziation)?

    CRC-Karten: Unter Kollaborationen werden generell nur die Klassen aufgeführt, die die spezifizierte Klasse zur Erfüllung ihrer Aufgaben benötigt.

  • Ist die Kardinalität * gleichbedeutend mit 0..*?

    Ja

  • Singleton-Muster: Verhindert der Konstruktor - so wie er implementiert ist - einen Default-Konstrukor wegen dem modifier private? Oder weil die Anweisung leer ist?

    Beim Singleton-Muster wird durch private erreicht, dass der Konstruktor von außerhalb der Klasse nicht mehr aufgerufen werden kann.

  • Wann genau benötige ich denn bei einem Zustandautomat die Einträge entry, do oder exit? Zum Beispiel beim Geldautomat in der Vorlesung: Kann ich da anstatt entry/prüfe Geheimzahl nicht nur sagen:prüfe Geheimzahl? Oder muss das so stehen damit klar wird, dass sobald man in den Zustand kommt, die Geheimzahl geprüft wird?

    Es ist meistens sinnvoll und notwendig, sowohl Zustandsname als auch entry/do/exit Aktionen anzugeben. In den meisten Prüfungsaufgaben wird das auch so verlangt. Meist ist es auch wirklich wichtig, zu unterscheiden, ob eine Aktion einmal beim Eintritt oder Verlassen des Zustands oder durchgehend während des Zustands ausgeführt wird.

  • Klassenoperationen werden in Java-Code mit static davor geschrieben. Wie kann es sein, dass die Konstruktoroperation eine Klassenoperation ist, obwohl ich selber noch nie ein static davor geschrieben habe?

    In Java wird implizit angenommen, dass die Konstruktoroperation eine Klassenoperation ist. Dass der Konstruktor eine Klassenoperation sein mus, ist auch klar: schießlich gibt es bei der Erzeugung eines Objekts und dem damit verbundenen Aufruf des Konstruktors noch gar kein Objekt, dem die Konstruktoroperation gehören könnte. Der Konstruktor muss also der Klasse gehören.

  • Java-Beans: Laut Skript wird die Quellkomponente beim Nachrichtentransfer mittels Event Adapter nicht blockiert. Wird der Event Adapter aber als einfache Klasse realisiert, deren Methode onEvent lediglich eine Methode der Zielkomponente aufruft, so wird die Quellkomponente doch - genauso, wie bei direkter Kommunikation - bis zur 'Rückkehr' des Kontrollflusses von der Zielkomponente blockiert. Wo steckt also der Fehler in dieser Argumentation?

    Nach dem beschriebenen Ablauf stimmt das. Stellen Sie sich einen anderen Ablauf vor: Um eine Blockierung der Quellkomponente zu vermeiden, empfängt der Event Adapter alle Events eines Verbindungstyps und schreibt sie in eine Event Queue. Zugleich arbeitet er diese Event Queue nach dem FIFO-Prinzip ab. Somit wird eine asynchrone blockierungsfreie Eventkommunikation erreicht.