Softwaretechnik (WS 11/12)

Transkript

1 Universität Augsburg, LSt. Softwaretechnik, K. Stenzel, H. Seebach, G. Anders Softwaretechnik (WS 11/12) Lösungsvorschlag 5 Aufgabe 1 (System Behavior: System Sequence Diagrams) (10/5 Punkte) a) Was sind die Systemoperationen? Vorbemerkung: Das UI ist bei uns bislang nicht Teil des Systems. Wir betrachten nur einen Systemkern, an den (via Systemoperationen) dann noch ein grafisches oder auch textbasiertes UI angeschlossen werden kann. Das Kennzeichen einer Systemoperation ist: Sie wird von außen angestoßen, i.a. durch eine Benutzerinteraktion. Dazu sammelt das UI die notwendigen Daten und ruft damit die Systemoperation auf. (UI-interne Dinge wie Benutzer gibt ein, Benutzer klickt etc. sind keine Systemoperationen.) Finden der Systemoperationen Um die Systemoperationen (anhand der Use Cases) zu identifizieren, geht man die Szenarien der Use Cases durch. Immer wenn der Benutzer Eingaben gemacht hat, und darauf das System etwas macht, hat man einen Kandidaten für eine Systemoperation. In unserem Beispiel macht der Benutzer in den Schritten 2./4.-5. Eingaben 1, das System reagiert in 3./6.-7. mit Prüfung der Eingaben und der Berechnung von Buchungsvorschlägen. Das liefert uns unsere ersten Kandidaten für eine Systemoperation: in 3. sehen wir, dass der Raumwunsch separat (und schon vor der Vorschlagsberechnung) geprüft werden soll. Das ergibt den Kandidaten prueferaumwunsch(raumwunsch), in 6. und 7. werden die Vorschläge berechnet, was den Kandidaten berechnebuchungsvorschlaege(buchungswunsch) 2 liefert. In sucht sich der Benutzer einen Vorschlag aus, modifiziert diesen noch leicht und gibt Titel und Beschreibung an. Daraus macht das System anschließend eine neue Buchung. Das liefert uns den nächsten Kandidaten: erstellebuchung(buchungsvorschlag, Titel, Beschreibung, (neuer) Zeitraum). Sind das alle? Nein, die Variationen und Erweiterungen müssen natürlich auch berücksichtigt werden. Es ist oft möglich, Varianten von UseCases durch entsprechende Parametrisierung auszudrücken. Nicht immer führt dies aber zu verständlicheren Systementwürfen. Erweiterungen erfordern i.a. zusätzliche Systemoperationen ist UI-intern. 2 Prinzipiell hat man zwei Möglichkeiten: man kann die verschiedenen Parameter einzeln oder verpackt an eine Systemoperation geben. Es ist meist besser, die Parameter zu verpacken: die Schnittstelle ist so robuster und übersichtlicher. Durch den Abstraktionsschritt ist sie auch verständlicher: Wir sagen nicht nur, was wir übergeben, sondern deuten auch schon an, wozu die Parameter verwendet werden sollen. 1

2 Softwaretechnik (WS 11/12) Übungsblatt 5 2 Die Erweiterung 1a. könnten wir abbilden, indem wir erstellebuchung einen zusätzlichen Parameter simulierterbenutzer geben, oder durch eine weitere Systemoperation setzesimuliertenbenutzer(benutzer). Diese dürfte natürlich nur von Administratoren aufgerufen werden. Weiteres: Da ein Buchungswunsch mit einem Benutzer assoziiert sein soll, muss bei berechnebuchungsvorschlaege der aktuelle Benutzer als Parameter mit übergeben werden. 3 Solche Dinge fallen einem aber i.a. erst beim Erstellen der Kontrakte für die Systemoperationen auf. Die Systemoperationen sind damit (a) prueferaumwunsch(raumwunsch) (b) berechnebuchungsvorschlaege(buchungswunsch, Benutzer) (c) erstellebuchung(buchungsvorschlag, Titel, Beschreibung, (neuer) Zeitraum, simubenutzer) In dem System Sequenz Diagramm wurde auf den simulierten Benutzer verzichtet. Sie müssen diesen Fall auch in den folgenden Aufgaben nicht berücksichtigen. Aufgabe 2 (System Behavior: System Operations & Contracts) (13 Punkte) Systemoperationen sind die Schnittstellen der Systembenutzer zum System. Wenn in der GUI ein Button angeklickt wird, sucht diese die Daten aus diversen Feldern zusammen und iniziiert die 3 Es wäre sauberer, diesen beim Login im System zu speichern. Aber wir wollen unser Modell jetzt nicht weiter verkomplizieren...

3 Softwaretechnik (WS 11/12) Übungsblatt 5 3 Systemoperation. Es stellt sich die Frage, ob man diese Felder einzeln an die Systemoperation übergibt (bessere Trennung von GUI und System), oder bereits vor der eigentlichen Systemoperation diese Felder in Objekte des Konzeptmodells transformiert und dann die Systemoperation mit diesen aufruft. Der zweite Ansatz erfordert zwar, dass die GUI Objekte aus dem System anlegen kann, hat dafür aber eine verständlichere Schnittstelle. Deshalb verwenden wir im Folgenden den zweiten Ansatz, in dem die Systemoperation z. B. mit einem Buchungswunsch aufgerufen wird, und nicht mit den vielen Attributen von diesem in der Systemoperation selbst wäre sonst der erste Schritt ohnehin die Erstellung von solchen Objekten gewesen. Wir möchten betonen, dass auch der Ansatz mit Einzelparametern richtig (und von der Schichtentrennung her sauberer) ist. Aber er leidet unter unübersichtlichen Schnittstellen. Eine weitere Möglichkeit ist es, den Datenanteil in reinen Datenbehälterklassen zu kapseln. Dann würden wir die Systemoperation z. B. mit BuchungswunschDaten aufrufen, woraus die Systemoperation dann intern ein echtes Buchungswunsch-Objekt erzeugen würde. Somit wäre die GUI wieder echt von Systeminterna getrennt. Der wichtigste Punkt der Beschreibung ist die des Kontrakts. Hier muss angegeben werden, wie die Systemoperation den Zustand des Systems verändert, also insb. geänderte Attributwerte, neu erstellte oder gelöschte Objekte, und neu erstellte oder gelöschte Assoziationen. Dabei reicht es nicht aus zu sagen, z.b. eine neue Buchung wurde erstellt, sondern man muss auch explizit 4 auflisten, womit diese assoziiert wird. Dazu überlegt man sich zuerst, was die Systemoperation so ungefähr macht. Dies verfeinert man anschließend, indem man anhand des vorliegenden Konzeptmodells sich Fragen in der folgenden Art stellt: erstellebuchung legt eine neue Buchung an. Eine Buchung hat Assoziationen zu Benutzer, Buchungswunsch, und Gesamtbelegungsplan. (Falls es eine Schachtelbuchung ist, außerdem noch zu weiteren Buchungen. Ansonsten -je nach Modellierung- zu Terminen, oder zu Buchungen und Terminen... ) Welche von diesen Assoziationen müssen für die neue Buchung erstellt werden und zu welchen Objekten? Dann klappert man die Liste ab und, wenn es was zu tun gibt, ergänzt man die entsprechend. Systemoperation prüferaumwunsch Operation prüferaumwunsch(rw: Raumwunsch) Beschreibung Prüft, ob es unabhängig von den bislang gemachten Buchungen überhaupt Räume gibt, die die Raumwünsche des Benutzers erfüllen. (Wenn nicht, ist eine Suche nach Buchungsvorschlägen sinnlos.) Vorbedingung Querverweise UseCases: (Einzel-/Mehrfach-/Periodische) Buchung anlegen, Buchung ändern, Einzeltermin hinzufügen, Einzeltermin ändern Ergebnisse boolean, das angibt ob Raumwunsch erfüllbar Das Attribut 5 rw.erfüllbar wurde entsprechend gesetzt. Systemoperation berechnebuchungsvorschläge Operation berechnebuchungsvorschläge(bw: Buchungswunsch, be: Benutzer) 4 Später sollte anhand der Kontrakte das Design und die Implementierung erfolgen. Daher ist es äußerst wichtig, dass in den Kontrakten alles explizit gemacht wird und keine -auch keine scheinbar offensichtlichen- Zustandsänderungen weggelassen werden. 5 Das Attribut war bislang noch nicht im Konzeptmodell enthalten und muss neu hinzugefügt werden.

4 Softwaretechnik (WS 11/12) Übungsblatt 5 4 Beschreibung Berechnet die Vorschläge aus möglichen Buchungen, die den Buchungswunsch bw des Benutzers erfüllen und nicht mit dem Gesamtbelegungsplan in Konflikt stehen. Vorbedingung Der zum Buchungswunsch bw assoziierte Raumwunsch ist erfüllbar. Querverweise UseCases: Buchung anlegen, Buchung ändern, Einzeltermin hinzufügen, Einzeltermin ändern Ergebnisse Liste, die die Buchungsvorschläge enthält Eine Menge von Buchungsvorschlagsobjekten wurde generiert, die mit dem Gesamtbelegungsplan konfliktfrei sind. Der Benutzer be wird mit dem Buchungswunsch bw assoziiert (macht). Für jeden Buchungsvorschlag bv: Assoziation erfüllt zu bw wurde erzeugt. Passende Termine t wurden erzeugt und zu bv assoziiert. Die Termine t sind so, dass sie den Gesamtbelegungsplan respektieren. Für jeden Termin t wurde der gebuchtezeitraum gesetzt und der Raum assoziiert. Der gebuchtezeitraum aller Termine zu bv ist modulo Kalenderwoche identisch und maximal. Systemoperation erstellebuchung Operation erstellebuchung(bv: Buchungsvorschlag, Titel: String, Beschreibung: String, nz: Zeitraum) Beschreibung Erstellt eine Buchung mit den übergebenen Daten. Vorbedingung Der neue Zeitraum nz ist im Zeitraum des Buchungsvorschlags enthalten. bv ist konfliktfrei zum Gesamtbelegungsplan. Querverweise UseCase: Buchung anlegen Ergebnisse Buchung, die angelegt wurde (Schachtel-)Buchung bu wurde erstellt. Attribute bu.titel und bu.beschreibung wurden auf Titel bzw. Beschreibung gesetzt. bu gehört user wurde angelegt, wobei user der Benutzer ist, der den Buchungswunsch gemacht hat. Der zu bv assoziierte Buchungswunsch wurde zur Buchung bu assoziiert (wurdegebuchtmit). Für alle Termine t aus bv. t.gebuchterzeitraum wurde auf nz eingeschränkt. t wurde mit bu assoziiert. bv wurde gelöscht (inkl. Assoziationen). bu wurde mit dem Gesamtbelegungsplan assoziiert.

5 Softwaretechnik (WS 11/12) Übungsblatt 5 5 Aufgabe 3 (GUI-Anbindung mit Subscribe & Publish) (2/5 Punkte)