SoftwareEngineering. Klausur HFU *** Wl3/4 * WS 2005/2006. (30 Punkte) Lineares Benotungsschema: 90 Punffie = Note 1, 30 Punkte = Note 4.

Transkript

1 SoftwareEngineering Klausur HFU *** Wl3/4 * WS 2005/2006 Lineares Benotungsschema: 90 Punffie = Note 1, 30 Punkte = Note 4 Aufgabe 1: (30 Punkte) Zum Fallbeispiel "Theater-Online" (s. Anhang) soll ein Softwaresystem entwickelt werden, das die beschriebenen Prozesse unterstützt. Die Anforderungen sind im Rahmen einer OOA zu modellieren: a) Ergänzen Sie das u.a. Use-Case-Diagramm durch weitere geeignete (primäre und sekundäre) Use Cases sowie die zugehörigen Akteure und Kommunikations-Beziehungen! Alle im Fallbeispiel erkennbaren Nutzungsfälle sollen abgedeckt sein. (10) b) Erstellen Sie die verbale Spezifikation für den Use Case "Tickets kaufen"! Bezüglich des Ablaufs verweisen Sie auf das Ergebnis von Aufg. c). (05) c) Zeichnen Sie für den Ablauf dieses Use Case ein Activity-Diagramm, in dem ggf. auch alternative oder parallele Aktivitäten eindeutig modelliert sind! (15) a) I

2 -2-

3 c) Aktivitäts-Diagramm "Tickets kaufen": Hinweis: Denken Sie auch an die Möglichkeit, AKivitäten im Ablauf parallel zu konzipieren! -3-

4 Aufgabe 2: (16 Punlde) Entwerfen Sie zum Fallbeispiel "Theater-Online'ein Klassendiagramm, das die Gegenstände des (fachorientierten) Problembereichs mit ihren gegenseitigen Assoziationen darstellt! Berücksichtigen Sie dabei sowohl die Kunden- und Abo-Verwaltung, als auch den Zugriff auf die Vorstellungen und den Verkauf der Tickets. Achten Sie besonders auf eine angemessene Modellierung der verschiedenen Kunden-Arten! Geben Sie für jede Klasse 1-2 charakeristische Attribute an (d.h. keine Methoden). Zusatzfrage: Welche weiteren Klassen kommen zum o.a. problemorientierten Klassendiagramm in der Phase des OOD neu hinzu? Nennen Sie 5 Beispiele! -4-

5 Aufgabe 3: (18 Punkte) Entwerfen Sie ein Sequenzdiagrammit den Objekt-lnteraktionen fur das nachstehend beschriebene Szenario und beachten Sie dabei strikt das MVC-Prinzip mit einer npassiven' GU -Komponente: Zu Beginn ist das fragliche Kunden-Objekt bereits instantiiert, d.h. seine Referenz im Controller bekannt. lm KundenobjeK gespeichert ist auch die Referenz für das zugehörige Abo-Konto. Zunächst werden auf Anweisung des Controller im GUI die Daten des Kundenobjekts abgebildet. Der Bediener drückt den dann Button "Abo-Konto löschen". Zur Kontrolle werden die Daten des Abo- Kontos nochmal im GUI gezeigt. Drückt der Bediener nun den Button "Löschen bestätigen", so wird die Löschung aus der Datenbank durchgeführt. Abschließend erfolgt im GUI eine Betätigung (Konto gelöscht"). fr Benuter I tl tl tl I Zusatzfragen: a) Welche Erkenntnisse für den Software-Entwurf liefern Sequenzdiagramme wie das obige? b) Welche Arbeitsschritte im OOD müssen dem Entwurf von Seguenzdiagrammen, wie im obigen spiel, vorausgegangen sein? -5-

6 Aufgabe 4: (18 Punkte) Entwerfen Sie ein Zustandsdiagramm für ein Controller-Objekt zur Steuerung der Zugangsprüfung bei einem Bankomaten! Legen Sie dabei folgenden Ablauf zu Grunde: Karte wird eingeschoben - Gültigkeit des Kartentyps (EC-Karte, Master-Card etc.) wird geprüft, falls nicht gegeben: Kartenauswurf mit Fehlermeldung - eventuelle Spene der Karte wird bei Remote-Spen-Server abgefragt, falls gesperrt: Kartenauswurf mit Fehlermeldung - PIN wird abgefragt - PIN wird auf Richtigkeit überprüft, falls falsch: 2 weitere Versuche, dann Karten-Spene und Karten-Auswurf - falls PIN konekt: Benutzeraktionen (Kontostand abfragen, Geld auszahlen) Anmerkungen: - Antwortet ein Remote-Server nach dem Timeout-lntervall nicht, so wird der Vorgang abgebrochen (Kartenausgabe). - Alle möglichen BenuEeraktionen (d.h. die eigentliche Nutzung des Bankomaten) sollen der Einfachheit halber zu einem Sub-Zustand "Benutzeraktion" zusammengefasst und hier nicht weiter ausgeführt werden. -6-

7 Aufgabe 5: (8 Punkte) Desion Pattem Erklärung mit Beispiel: Einfl uss auf SW-Architektur: Framework Erklärung mit Beispiel: Einfl uss auf SW-Arch itektur: Erklären Sie (bitte in Stichworten!!!) die beiden F"glf" "Design Pattern" und,,framework" (je mit Nennung eines Beispiels) und charakterisieren Sie lhren jeweiligen Einiuss aut Oie Softwarearchiteft"ur einer wendung! An- -7-

8 Anhang zur Klausur "Software-Engineering" Fallbeispiel zu Aufgaben I - 3: Ein Stadttheater möchte für seine Kunden-Services ein Online-Portal bereit stellen, über das es möglich ist, Spielplan-lnformationen zu erhalten,tickets zu kaufen, Abonnements abzuschließen und anderes. Die "Kunden" des Systems werden, sofern ihre Daten permanent gespeichert sind, in zwei Kategorien eingeteilt: "Registrierte Besucher" haben in einem Registrierungsdialog Daten zu ihrer Person hinterlegt (Name, Adresse, etc.). Sie erhalten eine Kunden-lD und ein Passwort und können damit ihre Ticket-Käufeinfacher abwickeln, sowie per Mail Informationen über besondere Ereignisse und Angebote erhalten, "Abonnenten" haben per Vorauszahlung ein Abonnement für die laufende Saison gekauft. Dies funktioniert wie ein Konto, von dem einzelne Ticketkäufe zu besonders günstigen Preisen abgebucht werden. Auch ihre Daten zur Person sind gespeichert. lst das Abo abgelaufen bzw. aufgebraucht, fallen sie automatisch in den Status eines "registrierten Besuchers" zurück und können ggf. durch erneute Abo-Zahlung wieder zu Abonnenten werden. Über die Systembedienung gibt es u.a. die folgenden Vorstellungen: lnteressenten können im Veranstaltungsangebot und weiteren lnformationsseiten des Theaters browsen sowie im Dialog Tickets für kommende Vorstellungen kaufen (Details s. unten). 'lm Verlauf eines Ticket-Kaufs oder auch in einem eigenständigen Dialog können sie ihre Daten als "registrierter Besuchef' eingeben und erhalten dann eine Kunden-lD. Als Dialogfunktion ist auch der Abschluss eines Abos möglich, in dessen Verlauf (falls nicht schon vorhanden) ebenfalls die Kundendaten erfasst werden - die Zahlung erfolgt über Kreditkarte oder per Rechnung. (Als besonderen Service gibt es eine Dialogfunktion, über die man bereits gekaufte Tickets wieder zum Verkauf anbieten kann, falls man mal verhindert ist. Diese Tickets werden dann in den Verkaufs-Dialogen anderer lnteressenteneben den Normal-Tickets angezeigt und können durch direkten Kontakt zwischen Anbieter und Käufer ( ) vermittelt werden.) lm Ticket-Verkaufs-Dialoo kann man zunächst im Spielplan blättern und ggf. eine Vorstellung auswählen. Das Platzschema wird angezeigt und man kann, falls verfügbar, ein oder mehrere freie Tickets zum Kauf markieren. (An dieser Stelle werden ggf. auch Tickets von Wiederverkäufern (s.o.) angeboten. Entscheidet man sich für diese, so wird ein Window für die Erfassung einer an den Anbieter geöffnet. Den Rest -Tickefuersand und Zahlung - wickeln Anbieter und Interessent dann direkt, d.h. ohne Unterstützung des Systems miteinander ab.) lm normalen Verkaufsablauf gibt es nach Auswahl der Tickets zwei Möglichkeiten: Hat der Käufer ein Abo, so gibt er nur die Abo-lD ein, Tickets und abzubuchender Betrag werden zur Kontrolle angezeigt, nach Bestätigungeht es weiter zur Schlussbearbeitung. Ohne Abo werden die Kundendaten (u.a. Post- und Mail- Adresse) erfasst, die Zuteilung einer Kunden-lD für künftige Fälle kann an dieser Stelle gewünscht werden. lst man aber bereits registrierter Kunde, so braucht man nur die Kunden-lD eingeben und die gespeicherten Adressdaten werden angezeigt und übernommen. Die Zahlung erfogt entweder per Kreditkarte, dann ist ein kurzer Dialog mit Eingabe der Kartendaten abzuwickeln. lm anderen Fall wird der Ticketverkauf als Reservierungebucht und eine Auftragsbestätigung/Rechnung vorbereitet. (Anmerkung zum Verständnis: Diese Rechnung muss in einer bestimmten Frist bezahlt werden, sonst verfällt die Reservierung.) In der Abschluss-Bearbeitung wird eine Bestätigungs-Mail ezeugt sowie die Abbuchung der Tikkets vom Platz-Bestand vorgenommen. Weiter werden - je nach vorangegangener Zahlungsart - entweder ein Versandauftrag für die Tickets oder die Auftragsbestätigung/Rechnung generiert. Aus verschiedenen Gründen (2.B. SchuE gegenticket-verlust) sollen Daten über einzelne Tikket-Verkäufe bis zum Termin der jeweiligen Vorstellung im System gespeichert bleiben. Kunden- und Verkaufs-Daten sind Bestandteil des Systems. Die verfügbaren Plätze pro Veranstaltung werden auf einem zentralen, schon vorhandenen Server gehalten und dort gepflegt. lm Falle von Kreditkarten-Zahlungen werden die Services der entsprechenden Institute aufgerufen. -8-