Klausur Softwaretechnologie WS 2011/12

Transkript

1 Fakultät Informatik Institut für Software- und Multimediatechnik, Professur Softwaretechnologie Technische Universität Dresden, Dresden Klausur Softwaretechnologie WS 2011/12 Prof. Dr.rer.nat.habil. Uwe Aßmann Name: Vorname: Immatrikulationsnummer: Aufgabe Maximale Punktanzahl Teil I 45 Teil II 45 Erreichte Punktanzahl Gesamt 90 Zum Bestehen der Klausur müssen mindestens 20 Punkte im Teil I (Analyse) und ebenfalls 20 Punkte im Teil II (Entwurf und Implementierung) erreicht werden. Hinweise: In der Klausur ist als Hilfsmittel lediglich ein A4-Blatt, beidseitig beschrieben, zugelassen. Die Klammerung der Aufgabenblätter darf nicht entfernt werden. Tragen Sie bitte die Lösungen auf den Aufgabenblättern ein! Verwenden Sie keine roten, grünen Stifte oder Bleistifte! Es ist kein eigenes Papier zu verwenden! Bei Bedarf ist zusätzliches Papier bei der Aufsicht erhältlich. Bitte jedes zusätzliche Blatt mit Name, Vorname und Immatrikulationsnummer beschriften. Es sind alle Aufgabenblätter abzugeben! Ergänzen Sie das Deckblatt mit Name, Vorname und Immatrikulationsnummer! Halten Sie Ihren Studentenausweis und einen Lichtbildausweis zur Identitätsprüfung bereit. Achtung! Das Zeichen am linken Seitenrand heißt: Java-Text ist einzufügen!

2 2 Teil I (Analyse) Aufgabe I-1: Lebenszyklus eines Bugs (20 Punkte) Bugtracker sind häufig verwendete Werkzeuge in der Softwareentwicklung, die den Lebenszyklus eines Bugs verwalten. Dabei wird der Begriff Bug nicht nur für Fehler, sondern auch für Anfragen, für neue Funktionen (Feature Requests) und sonstige Aufgaben verwendet. Deshalb haben diese Systeme häufig auch andere Bezeichnungen wie zum Beispiel Trouble Ticket System oder Issue Tracker. Der Begriff Tracker wird deshalb gern verwendet, weil diese Werkzeuge alles verfolgen (engl.: track), was einen eindeutigen Anfangs- und Endzustand sowie Übergangszustände und damit einen Lebenszyklus hat. Wir konfigurieren einen einfachen Lebenszyklus eines Bugs in einem Bugtracker unserer Wahl wie folgt: Jemand reicht einen Bug in das System zusammen mit einem Namen (name) und einer Beschreibung (description) ein (createbug()). Dieser Bug wird zunächst als new deklariert. Andere lesen den Bug, fügen ggfs. Kommentare hinzu und reproduzieren den Bug (test()). Falls dieser Bug genügend Zustimmung erhalten hat, wird er vom Tester als confirmed bestätigt (confirm()). Der Bug kann aber auch aus verschiedenen Gründen zur Bearbeitung abgelehnt werden (notfixable()) und wird mit einer entsprechenden Kennzeichnung als resolved erklärt. Danach kann der Tester den Bug einem Entwickler zur Bearbeitung zuweisen (assign()) und den Bug als assigned kennzeichnen. Jetzt kann der Entwickler an einer Lösung für den Bug arbeiten und die jeweiligen Zwischenstände in die Versionsverwaltung (z.b. SVN) einchecken (isworkingon()). Es kann auch sein, dass der Entwickler die Behebung des Bugs ablehnt (reassign()) und der Bug danach manuell einem anderen Entwickler zugewiesen werden muss (assign()). Wenn der Entwickler der Meinung ist, den Bug gefixt zu haben, checkt er die geänderte Software in die Versionsverwaltung ein (fixcheckin()) und erklärt den Bug als resolved. Ein Tester hat nun die Aufgabe den Fix in evtl. mehreren Schritten zu testen (test()). Bei einem negativen Endergebnis wird der Bug wieder auf confirmed gesetzt (notsatisfiedsolution()) und muss damit in eine erneute Bearbeitungsrunde gehen. Bei einem positiven Testergebnis wird der Bug als verified erklärt (satisfiedsolution()). Grundsätzlich kann dieser geprüfte (verified) Bug wieder geöffnet werden (reopen()) und der gesamte Lebenszyklus beginnt als neuer (new) Bug von vorn. Im Allgemeinen jedoch wird der Bug geschlossen (close()), was das Ende des Lebenszyklus dieses Bugs bedeutet. Lösen Sie folgende Teilaufgaben: a) (2 Punkte) Ergänzen Sie das folgende zugehörige UML-Analyse-Klassendiagramm um die Beschreibung des Zustandes des Bugs! Nutzen Sie dazu eine UML-Enumeration!

3 3 b) (18 Punkte) Modellieren Sie den Lebenszyklus eines Bugs entsprechend der obigen Beschreibung in Form einer UML-Protokollmaschine! Verwenden Sie für die Modellelemente der Protokollmaschine die kursiv festgelegten (engl.) Namen und die in Klammern geschriebenen Methodenaufrufe!

4 4 Aufgabe I-2: Auktionen (25 Punkte) Bei der bekannten Englischen Auktion (Auction) werden, von einem festgesetzten Einstandspreis von einem Posten (minprice) beginnend aufsteigend Gebote abgegeben, bis kein neues Gebot mehr eintrifft. Der letzte Bieter erhält den Zuschlag. Die Entwickler eines Auktionssystems beginnen mit der CRC-Karten-Analyse. Zunächst haben sie vier Klassen identifiziert: Auction für die einzelnen Auktionen. Jede Auktion kennt eine Liste ihrer zu versteigernden Posten (allitems) und eine Liste aller Bieter (bidders). Item für die Posten, die für eine Versteigerung vorgesehen sind. Ein Item hat eine Beschreibung (description) und bekommt eine Nummer (number) sowie einen Einstandspreis (minprice) zugewiesen. Jeder Posten kennt alle auf sich abgegebenen Gebote (allbids). Posten existieren nur für eine Auktion und werden wieder gelöscht, wenn die Auktion geschlossen wird. Bid für die Gebote. Ein Gebot wird beschrieben durch einen Preis (price) und wird von einer Person (bidder) abgegeben. Person für alle Personen, die als Bieter eines Postens in der Auktion auftreten. Von jeder Person wird der Name (name) gespeichert. Dann haben die Entwickler eine Auktion durchgespielt und das Szenarium in einem UML- Sequenzdiagramm protokolliert (siehe nächste Seite). Achtung, Max, Moritz und der Auktionator (Auctioneer) sind Akteure in der durchgespielten Auktion: Zunächst eröffnet (erzeugt) ein Auktionator eine Auktion (openauction()). Danach registriert er die zu versteigernden Posten, indem er diese im System erzeugt und in einer Liste (allitems) registriert (registeritem()). Nachdem alle Posten registriert sind, kann die eigentliche Auktion beginnen, indem die Bieter Gebote (einen Preis) für einen bestimmten Posten abgeben (biditemby()). Das System vergleicht das abgegebene Gebot mit dem derzeit höchsten Gebot und erzeugt ein neues Gebot (Bid). Sofern der gebotene Preis (price) den Einstandspreis erreicht oder das derzeit höchste Gebot (highestbid) für den Posten überschreitet (bidby()), wird ein neues Höchstgebot (highestbid) vermerkt (sethighestbid()). Für jedes Gebot wird der (genau ein) Bieter (bidder) vermerkt. Alle Bieter der Auktion werden genau einmal in einer Kollektion (bidders) gespeichert. Wenn keine neuen Gebote eintreffen, schließt der Auktionator die Auktion (closeauction), indem das Ergebnis der Auktion angezeigt wird (showauctionresult). Lösen Sie folgende Teilaufgaben: a) (8 Punkte) Skizzieren Sie die vier entsprechenden CRC-Karten (nur Vorderseite) mit den Informationen, wie sie sich aus dem Rollenspiel ergeben haben! Achtung, Karten können auch fast leer sein.

5 5

6 6 b) (9 Punkte) Erstellen Sie das zugehörige Analyseklassendiagramm und achten Sie auf Konsistenz zu den CRC-Karten! Beschreiben Sie zusätzlich die Klassenbeziehungen! c) (8 Punkte) Erstellen Sie ein Objektdiagramm mit den Objekten aus dem Rollenspiel! Achten Sie auf Konsistenz zum Klassen- und Sequenzdiagramm! Das Objektdiagramm soll den Zustand des Programmes unmittelbar vor Aufruf der Methode closeauction() repräsentieren.

7 7 Teil II (Entwurf und Implementierung): Aufgabe II-1: Auktionssystem (45 Punkte) Nach der Analyse unseres Auktionssystems (siehe Aufgabe I-2) wurde das Analysemodell zu einem (noch unvollständigen) Entwurfsmodell verfeinert und verändert ( Chicken Fattening ). Implementieren Sie im Folgenden das Auktionssystem! Gehen Sie dabei wie folgt vor und lösen Sie folgende Teilaufgaben: a) (5 Punkte) Ergänzen Sie das unten stehende Entwurfsmodell und berücksichtigen Sie dazu folgende Anforderungen und Entwurfsentscheidungen: (1) Denken Sie darüber nach, wie die Methode openauction() implementiert werden kann und ändern Sie ggfs. den Namen der Methode! Ergänzen Sie die Methode! (2) Ergänzen Sie Attribute und verwenden Sie dafür die folgenden Datentypen: int für number eines Postens. Die Nummerierung von Posten soll mit 1 beginnen. long für Preise (minprice, price) String für die Beschreibung (description) eines Postens und den Namen (name) einer Person Alle diese Attribute sollen (einmal initialisiert) nicht mehr überschrieben werden (in der Implementierung zu beachten!). (3) Die Klassen wurden bereits um Hilfsmethoden ergänzt. Die Beschreibung dieser Methoden finden Sie im nachfolgenden Java-Code. Ergänzen Sie im Laufe der Implementierung weitere benötigte Hilfsmethoden (wie z.b. getter) und Hilfsvariablen! b) (33 Punkte) Implementieren Sie das Entwurfsmodell in Java (Klassen Auction und Item)! Achten Sie auf Konsistenz aller Namen zwischen den Modellelementen und Java-Namen. Als Hilfestellung ist der nachfolgende Java-Code gegeben! Ergänzen Sie diesen und beachten Sie dabei folgende Anforderungen:

8 8 (1) Verwenden Sie für Kollektionen geeignete generische Datenstrukturen! (2) Geben Sie Fehlermeldungen auf der Konsole aus! Nutzen Sie zur Vereinfachung dazu die Methode public void error(string message) (muss nicht implementiert werden). import java.util.*; public class Auction { // Variablen // Konstruktor public void showitemlist() { Item item; for (int i = 0; i <= allitems.size()-1; i++) { item = allitems.get(i); System.out.println(item); Bid highestbid = item.gethighestbid(); if(highestbid!= null) { System.out.println( "Gebot: " + highestbid.getprice() + " durch " + highestbid.getbidder()); else System.out.println("kein Gebot"); /* Bei einer englischen Auktion bekommt der Bieter mit dem Höchstgebot den Zuschlag. Das bedeutet in unserem Fall, dass lediglich die Liste allitems angezeigt wird. */ public void showauctionresult() { /* Hilfsmethode zum Finden eines Postens (Item) in der Liste allitems unter Angabe der Postennummer(number). Falls es keinen entsprechenden Posten gibt, wird null zurück gegeben. */ private Item getitem(int number) {

9 9 /*Hilfsmethode, die die Person zurück gibt, wenn der Bieter (name) bereits andere Gebote abgegeben hat, also in der Kollektion bidders enthalten ist. Ansonsten erzeugt die Methode einen neuen Bieter (Person), fügt diesen in die Kollektion bidders ein und gibt diesen zurück. */ private Person alreadyabidder(string name) { // weitere (drei) Methoden der Klasse Auction (siehe Modell) // Ende der Klasse Auction

10 10 public class Item { // Variablen // Konstruktor muss nicht implementiert werden /* Hilfsmethode, die true zurück liefert, falls der Preis (price) eines Gebotes unter dem Mindestpreis (minprice) des Postens liegt. */ private boolean islessthanminprice(long price) { // weitere (zwei) Methoden der Klasse Item (siehe Modell) // Ende der Klasse Item

11 11 c) Nachdem das Auktionssystem implementiert wurde, fordert der Kunde eine Erweiterung des Systems in der Weise an, dass neben den Englischen Auktionen auch All-Pay-Auktionen unterstützt werden. Eine All-Pay-Auktion ist eine Auktion, bei der derjenige mit dem Höchstgebot den Zuschlag erhält, aber alle Mitbietenden ebenfalls ihr Gebot zahlen. Das bedeutet für unser Auktionssystem, dass als Auktionsresultat (showauctionresult()) pro Posten nicht nur das Höchstgebot, sondern alle Gebote aufgelistet werden (showallbids()). (7 Punkte) Überlegen Sie, wie durch Refaktorisierung des Entwurfsmodells und unter Verwendung des Template Method-Entwurfsmusters diese Kundenanforderung realisiert werden kann. Beginnen Sie mit der Überlegung, wie die Methode showitemlist()refaktorisiert werden kann und skizzieren Sie in Java Ihre Lösung: Skizzieren Sie Ihren Entwurf in einem UML-Diagramm und zeichnen Sie das Entwurfsmuster in UML-Notation ein!