Softwaretechnik (WS 11/12)

Transkript

1 Universität Augsburg, LSt. Softwaretechnik, K. Stenzel, H. Seebach, G. Anders Softwaretechnik (WS 11/12) Lösungsvorschlag 1 Aufgabe 1 (MagicDraw / UML Use Cases) (20/15 Punkte) Vorbemerkung: Use Cases sollen primär der Kommunikation mit dem Kunden dienen. Bevor die Entwicklung eines Systems beginnt, muss sichergestellt werden, dass die Anforderungen überhaupt richtig verstanden worden sind. Use Cases sind hierfür ein zentrales Hilfsmittel. Da sie weitestgehend textuell sind, können sie auch von Nicht-Informatikern gut verstanden werden - wenn sie gut geschrieben sind. Stellen Sie sich beim Bearbeiten der Aufgaben immer vor, dass Sie die Dokumente nicht für Übungsleiter und Korrekteure erstellen, sondern für Ihren Kunden. Sie wollen ihm damit zeigen, dass Sie sein Problem verstanden haben und er Ihnen für dessen Lösung vertrauensvoll Geld geben kann. a) Welche Vorgänge sind Use Cases? Use Cases sollen einem Akteur nutzen, ein bestimmtes, eigenständiges beobachtbares Ziel haben (und insbesondere nicht auf zu kleine Details fokussiert sein). Ein Use Case muss in relativ kurzem Zeitrahmen zu erledigen sein, d.h. eine Aktivität, die mehrere Stunden oder gar Tage in Anspruch nimmt, ist eher als Geschäftsprozess (der seinerseits wiederum Use Cases enthalten kann) aufzufassen. Von den oben genannten Vorgängen sind die folgenden Use Cases: Einzelbuchung anlegen (ebenso: Mehrfachbuchung bzw. periodische Buchung anlegen) Alternativ: Ein großer Use Case Buchung anlegen für die drei Buchungstypen. Termin einer Buchung löschen Belegungsplan drucken Keine Use Cases sind Rechner in Betrieb nehmen: bevor der Rechner nicht läuft, gibt es das System noch gar nicht. Benutzer verwalten: zu unspezifisch, kein Ziel, eher: Verantwortlichkeit oder Gruppe von Use Cases DB-Verbindung aufbauen: interne Aktion, keine Benutzerinteraktion, kein Ziel des Akteurs Suchkriterien eingeben: Teil von u.a. Einzelbuchung anlegen, nicht eigenständig, zu elementar Berechnung der Buchungsvorschläge: s.o. Je nachdem, wie man den Vorgang interpretiert, kann man manche Vorgänge als Use Cases sehen oder auch nicht. Es kommt auf die Begründung an. Beispielsweise kann man auch Belegungsplan erstellen als einen Use Case auffassen, dann wäre Belegungsplan ausdrucken eine Erweiterung zu diesem und nicht unbedingt mehr als eigenständiger Use Case anzusehen. b) Restliche Use Cases Benutzer anlegen/ändern/löschen Raum anlegen/ändern/löschen Einzelbuchung/Mehrfachbuchung/Periodische Buchung anlegen/ändern/löschen (Wenn man die Vorgänge für zu unterschiedlich für eine simple Variation hält: unterschiedliche Use Cases, sonst Use Case Buchung anlegen verwenden. 1

2 Softwaretechnik (WS 11/12) Übungsblatt 1 2 Benutzer anmelden (login) Wenn die Authentifizierung nicht nur über Benutzername und Kennwort erfolgt, sondern zum Beispiels mittels Smartcards oder biometrischen Daten, kann der Login auf jeden Fall als Use Case angesehen werden. Wenn eine für sich abgeschlossene Aktion zwar keinen direkten Geschäftswert hat, aber häufig vorkommt und wichtig ist, dann kann sie ebenfalls als eigener Use Case angesehen werden. c) Grobbeschreibungen zu den Use Cases. Die Grobbeschreibung zu Einzelbuchung anlegen ist sehr ungenau: sie macht keine Aussage darüber, was eine Buchung ist, oder wer was für Buchungen anlegen darf. Dagegen ist Einzeltermin hinzufügen relativ gut ausgearbeitet. In der Praxis wird man i. A. erst mit sehr groben Beschreibungen anfangen und diese dann nach und nach ausarbeiten. Dabei ist es wichtig, eng mit dem Kunden zusammenzuarbeiten, damit man nicht beginnt, an dessen Wünschen vorbei zu entwickeln. Benutzer anlegen Trigger: ein neuer Benutzer möchte das System benutzen Beschreibung: Administrator fügt einen neuen Benutzer zur Liste der vorhandenen Benutzer hinzu. Querverweis: Kundenanforderungen, 3.3, 3.4 Benutzer ändern Trigger: die Daten eines Benutzers haben sich geändert Beschreibung: Administrator ändert die Daten eines bestehenden Benutzers. Querverweis: Kundenanforderungen, 3.3, 3.4 Benutzer löschen Trigger: ein bisheriger Benutzer möchte das System nicht weiter nutzen Beschreibung: Administrator löscht einen Benutzer aus der Liste der vorhandenen Benutzer. Geht nur, wenn keine Buchungen auf diesen Benutzer mehr vorhanden sind. Querverweis: Kundenanforderungen, 3.3 Buchung ändern Trigger: Ein Benutzer möchte eine seiner Buchungen ändern. Beschreibung: Der Benutzer ändert eine seiner bestehenden Buchungen. Er kann Titel, Kommentar ändern, aber auch die Buchung komplett verschieben. Bereits vergangene Termine sind nicht betroffen. Querverweis: Kundenanforderungen, Einzelbuchung anlegen Trigger: Ein Benutzer benötigt einen Raum zu einer gewissen Zeit. Beschreibung: Der Benutzer möchte eine neue Einzelbuchung anlegen. Dazu gibt er Randbedingungen vor, das System versucht, diese möglichst gut zu erfüllen. Der Benutzer legt dann auf Grundlage eines Systemvorschlags eine neue Einzelbuchung an. Querverweise

3 Softwaretechnik (WS 11/12) Übungsblatt 1 3 Kundenanforderungen, 3.1 (Buchen von Veranstaltungsräumen) Kundenanforderungen, 3.7 ( -bestätigung) Mehrfachbuchung anlegen Trigger: Ein Benutzer benötigt eine gewisse Raumkapazität zu einer bestimmten Zeit. Beschreibung: Der Benutzer legt eine neue Mehrfachbuchung an. Querverweise Kundenanforderungen, 3.1 (Buchen von Veranstaltungsräumen) Kundenanforderungen, 3.7 ( -bestätigung) Periodische Buchung anlegen Trigger: Ein Benutzer benötigt immer wieder einen Raum. Beschreibung: Der Benutzer legt eine neue periodische Buchung an (vgl. Einzelbuchung). Unterschied: Für periodische Buchung muss der Benutzer zusätzlich die Periode spezifizieren. Querverweise Kundenanforderungen, 3.1 (Buchen von Veranstaltungsräumen) Kundenanforderungen, 3.7 ( -bestätigung) Buchung löschen Trigger: Der Grund für eine Buchung wurde hinfällig, der Raum kann anderweitig vergeben werden. Beschreibung: Der Benutzer löscht eine seiner bestehenden Buchungen. Es können nur die Termine gelöscht werden, die in der Zukunft liegen. Querverweis: Kundenanforderungen, Einzeltermin ändern Trigger: Es hat sich eine Terminverschiebung ergeben. Beschreibung: Der Benutzer sucht nach einer seiner Buchungen. Er wählt einen Einzeltermin daraus aus und wählt Ändern aus. Der Benutzer ändert einen Einzeltermin aus einer seiner bestehenden Buchungen. Er kann Titel, Kommentar ändern, aber auch den Termin verlegen. Es gelten dieselben Einschränkungen wie bei Einzeltermin hinzufügen. Querverweis: Kundenanforderungen, , , Einzeltermin hinzufügen Trigger: Ein Benutzer benötigt im Rahmen einer bestehenden Buchung einen weiteren Termin. Beschreibung: Der Benutzer sucht nach einer seiner Buchungen. Er wählt einen Einzeltermin hinzufügen aus. Der Benutzer fügt zu einer seiner bestehenden Buchungen einen weiteren Einzeltermin hinzu. Er kann Raum und Termin dafür frei wählen (wenn der Raum noch frei ist). Der Zeitpunkt des neuen Termins muss in der Zukunft liegen, der Raum darf zu diesem Termin noch nicht gebucht sein. Querverweis: nicht in den Kundenanforderungen, nützliche Verallgemeinerung Anmerkung: den Kunden fragen, ob er den Punkt übersehen hat

4 Softwaretechnik (WS 11/12) Übungsblatt 1 4 Einzeltermin löschen Trigger: Ein Termin einer Buchung entfällt, der Raum kann anderweitig vergeben werden. Beschreibung: Der Benutzer sucht nach einer seiner Buchungen. Er wählt einen Einzeltermin daraus aus und wählt Löschen aus. Geht nur, wenn der Termin in der Zukunft liegt. Wird der letzte Termin gelöscht, so wird die Buchung mitgelöscht. Querverweis: Kundenanforderungen, Login Trigger: Ein Benutzer möchte mit dem System arbeiten. Beschreibung: Benutzer meldet sich durch Eingabe von Benutzernamen und Passwort beim System an. Querverweis: Kundenanforderungen, 3.4 Raum ändern Trigger: Die Daten eines Raums haben sich geändert. Beschreibung: Administrator ändert die Daten eines bestehenden Raums. Querverweis: Kundenanforderungen, 3.5 Raum anlegen Trigger: Ein weiterer Raum soll mit dem System verwaltet werden. Beschreibung: Administrator fügt einen neuen Raum zur Liste der vorhandenen Räume hinzu Querverweis: Kundenanforderungen, 3.5 Raum löschen Trigger: Ein Raum soll nicht mehr mit dem System verwaltet werden. Beschreibung: Administrator löscht einen Raum aus der Liste der vorhandenen Räume. Geht nur, wenn keine Buchungen auf diesen Raum mehr vorhanden sind. Querverweis: Kundenanforderungen, 3.5 Man sieht schon hier, dass es ratsam ist, die Use Cases Benutzer anlegen/ändern/löschen zumindest grafisch zur Use Case Gruppe Benutzerverwaltung zu gruppieren, und auf diese Weise die Menge an Use Cases zu reduzieren. d) Detaillierte Dokumentation zum Use Case Einzelbuchung anlegen Trigger: Ein Benutzer benötigt einen Raum zu einer bestimmten Zeit. Scope: Raumplanungssystem Typ/Level: primär, Benutzer Beschreibung/Context of Use: Der Benutzer legt eine neue Einzelbuchung an. Querverweise: Kundenanforderungen, 3.1 (Buchen von Veranstaltungsräumen) Kundenanforderungen, 3.7 ( -bestätigung) Stakeholders and Interests

5 Softwaretechnik (WS 11/12) Übungsblatt 1 5 Benutzer: Möchte möglichst effizient eine neue Einzelbuchung anlegen. Dabei darf auf keinen Fall eine Raum-/Terminkollision auftreten. Idealerweise unterstützt ihn das System bei der Suche nach geeigneten Räumen und Terminen. Hausmeister: möchte aktuelle Informationen darüber zur Verfügung haben, wann welcher Raum belegt ist. Vorbedingung: Der Benutzer ist angemeldet, Gesamtbelegungsplan ist konfliktfrei. Minimale Garantien: Keine Konflikte, keine existierenden Buchungen wurden verändert. Erfolgsgarantie: Eine neue Einzelbuchung wurde angelegt. Diese steht nicht in Kollission mit den anderen Buchungen. Der Benutzer wurde durch eine über den Erfolg informiert. Hauptszenario (Zur Erinnerung: Das Hauptszenario sollte immer ohne Fehler zu Ende kommen.) I. Auswahl 1. Benutzer wählt Neue Einzelbuchung anlegen II. Spezifikation der Suchanfrage 2. Benutzer spezifiziert Kriterien für geeignete Räume. Dazu sind relevant erforderliche Platzzahl Gebäude, in dem der Raum liegt Raumtyp (Besprechungsraum, Labor,...) Inventar (Tafel, Beamer, Projektor) 3. System prüft Raumwunsch unabhängig von der aktuellen Belegung. 4. Benutzer spezifiziert den Zeitraum, in dem gesucht werden soll. Er gibt Starttag und -zeit und Endtag und -zeit an. Bsp.: Di 10:00 bis Mi 14:00 heißt nicht Di 10:00-14:00, Mi 10:00-14:00, sondern Di 10:00-20:00 und Mi 8:00-14:00. 5 Benutzer spezifiziert die Dauer. 6. System prüft Eingaben auf Konsistenz, berechnet nicht ausgefüllte Daten. Buchungszeitgrenzen 8:00-20:00 Uhr. Die Zeiten sind jeweils auf volle 15 Minuten anzugeben. III. Vorschlagsberechnung und -auswahl 7. System berechnet Vorschläge für mögliche Buchungen 8. Benutzer wählt einen Vorschlag aus. 9. Benutzer schränkt den angebotenen Zeitraum auf seine Bedürfnisse ein. 10. Benutzer gibt Titel und Beschreibung der neu zu erstellenden Buchung an. 11. Benutzer bestätigt seine Buchung. 12. System legt die Buchung an.

6 Softwaretechnik (WS 11/12) Übungsblatt System bestätigt die erfolgreiche Durchführung. 14. System schickt -bestätigung an -adresse des aktuellen Benutzers. Variationen *a Der Benutzer überlegt es sich anders und bricht das Anlegen einer neuen Buchung ab. 1a. Der Administrator darf für andere Benutzer buchen. Er kann sich einen Benutzer aussuchen, für den er eine Buchung anlegen möchte. Bei der Buchung muss sowohl vermerkt werden, welcher Benutzer die Buchung erstellt hat, als auch wem sie gehört. 3a. Der Raumwunsch ist unabhängig von der aktuellen Belegung nicht erfüllbar (z.b. wenn es gar keinen so großen Raum gibt). 1. System informiert Benutzer. 2. Der Benutzer fährt mit 2. fort. 4a. Der Zeitraum kann in Kalenderwochen (KW) angegeben werden. 5a. Benutzer spezifiziert keine Dauer. 1. System interpretiert gesamten Zeitraum als Dauer. 6a. Es bestehen Widersprüche in den Eingaben. 1. System informiert Benutzer. 2. Der Benutzer fährt mit 5. fort. 7a. Die Suchanfrage ist nicht erfüllbar. 1. System meldet dies dem Benutzer. 2. Der Benutzer fährt mit 2. fort. 8a. Vorschläge entsprechen nicht den Vorstellungen des Benutzers 1. Benutzer lehnt die Vorschläge ab und geht zurück zu 2., 4. oder 5. und modifiziert die Kriterien seiner Suchanfrage. 12a. Buchung konnte nicht angelegt werden. 1. System informiert den Benutzer. 2. Der Benutzer fährt mit 8. fort. Special Requirements Das System soll auch von ausländischen Beschäftigten oder in internationalen Filialen eingesetzt werden. Daher muss Internationalisierung zumindest in Form wählbarer Sprache unterstützt werden. Technology and Data Variations List Frequency of Occurrence: mehrmals täglich Open Issues: Soll bei Ausfall der Datenbankanbindung eine vorläufige Buchung möglich sein? Einsatz verteilter Datenbanken damit kein zentraler Ausfallpunkt besteht? Soll das System im Konfliktfall ein interaktives Verschieben der in Konflikt stehenden Termine ermöglichen? Soll der zu buchende Zeitraum während der Eingabe der restlichen Daten reserviert werden oder gibt es eine andere Regelung um Doppelbuchungen zu verhindern? Anmerkung: In der Beschreibung des Hauptszenarios sollte man konkret angeben, welche Informationen zwischen Akteuren und System fließen müssen. Nur anzugeben, dass Daten

7 Softwaretechnik (WS 11/12) Übungsblatt 1 7 eingegeben werden (aber nicht was für welche) reicht nicht aus, um einen Use Case verständlich zu beschreiben. Andererseits sollte man auf Angaben wie das System zeigt ein Formular an verzichten, da das Anzeigen des Formulares hier nicht wesentlich ist.

8 Softwaretechnik (WS 11/12) Übungsblatt 1 8 e) Modellierung in MagicDraw Den Lösungsvorschlag zur Modellierung in MagicDraw finden Sie als Angabe für das nächste Blatt auf der Übungsseite im Web zum Download. Das Use Case Diagramm sieht wie folgt aus: In der Beschreibung (im MagicDraw Modell) des Use Cases Buchung anlegen gibt es keine Unterscheidung zwischen periodischen, Einzel- oder Mehrfachbuchungen. Man sieht anhand des Diagramms, dass ein Use Case Diagramm zwar gut geeignet ist, um einen Überblick über die vorhandenen Use Cases zu geben und in gewissem Maße auch über die Beziehung zwischen Akteuren und Use Cases bzw. zwischen Use Cases untereinander. Das Wesentliche sind aber die Use Cases selbst und diese sind rein textuell. Die Diagramme spielen dem gegenüber eine stark untergeordnete Rolle. Kurzbeschreibung: Wir unterscheiden zwei Benutzerklassen: normale Benutzer können lediglich neue Buchungen erstellen und ihre eigenen Buchungen ändern oder löschen. Außerdem können sie sich Belegungspläne erstellen lassen. Administratoren sind zusätzlich in der Lage, die Stammdaten (Räume, Gebäude, Benutzer) zu verwalten. Ein Administrator kann zusätzlich alle Vorgänge durchführen, die auch ein normaler Benutzer durchführen kann. Dies ist durch

9 Softwaretechnik (WS 11/12) Übungsblatt 1 9 die Spezialisierungsbeziehung ausgedrückt. Jeder Administrator ist ein (spezieller) Benutzer und kann daher auch alles, was ein (normaler) Benutzer kann. Kommentar Wenn man versucht etwas gut zu dokumentieren, führt dies zwingend dazu, dass man es selbst besser versteht. Oftmals führt der Versuch etwas zu dokumentieren auch zu der Erkenntnis, dass eine Überarbeitung sehr vorteilhaft wäre. Bereitet dagegen die Dokumentation sehr viel Mühe, so ist womöglich der Code, das Modell schlecht. Fazit: Dokumentation ist wichtig und nützlich!