2. Übung zu Software Engineering

1. 2. Übung zu Software Engineering WS 2007/2008

2. Organisatorisches • „[SE]“ als Teil des E-Mail-Betreffs • nicht: SE, Software Engineering, Blatt 01 etc. • Abgabe: EINE pdf-Datei, spätestens 11:30 Uhr • nicht: xls, doc, rar oder zip

3. Aufgabe 2 • Die Durchführung eines Großprojekts sei in die folgenden Vorgänge untergliedert:

4. Aufgabe 2a) • Erstellen Sie einen Projektplan für das beschriebene Projekt mit einem Projektplanungstool Ihrer Wahl. Gehen Sie davon aus, dass das Projekt mit 4 Mitarbeitern am 12. November 2007 beginnt und dass jeder Vorgang nur von genau einem Mitarbeiter bearbeitet werden kann. Bestimmen Sie den kritischen Pfad des Projekts. Wann ist das Projekt abgeschlossen?

5. Aufgabe 2a) • Vorgänge eingeben und verknüpfen • siehe Tabelle • Vorgangsdauer eintragen • siehe Tabelle • Ressourcen eintragen und zuordnen • 4 beliebige Ressourcen anlegen • jeder Vorgang darf nur von einer Ressource bearbeitet werden • Kritischer Pfad: Vorgänge 1, 5, 6 und 9 • Frühester Endtermin: 13. Dezember 2007 • Dauer: 24 Werktage bzw. 32 Kalendertage (inkl. Wochenenden)

6. Aufgabe 2a)

7. Aufgabe 2b) • Erstellen Sie einen Netzplan für das Projekt und bestimmen Sie für jeden Vorgang den frühesten Anfang, das späteste Ende sowie die Pufferzeit. Ermitteln Sie erneut den kritischen Pfad. Setzen Sie dabei den Anfang des ersten Vorgangs auf 0 statt mit konkreten Datumsangaben zu rechnen. Stimmt der so ermittelte kritische Pfad mit dem aus Ihrem Projektplan überein?

8. Aufgabe 2b) • Netzplantechnik • frühester Anfang • Vorwärtsterminierung • FAi = max{FAj + Dauerj mit j ∈ Vorgänger von Vorgang i} • FAStartvorgang = 0 • spätestes Ende • Rückwärtsterminierung • SEi = min{FAj - Dauerj mit j ∈ Nachfolger von Vorgang i} • SEEndvorgang = max{FAj + Dauerj mit j ∈ Vorgänger von Endvorgang} • Pufferzeit • PZ = SA - FA = SE - FA - Dauer, da SA = SE - Dauer • kritischer Pfad = Vorgänge mit 0 Pufferzeit • frühestes Ende, spätester Anfang

9. Aufgabe 2b) 3 8 6 16 16 24 7 5 1 3 3 0 6 6 0 4 9 6 16 16 24 2 9 1 6 8 0 0 6 12 16 5 1 4 0 5 6 12 6 0 7 Nr. 12 24 FA SE 11 1 D PZ

10. Vorgang 1 Dauer = 6 FA = 0 (per Definition) SE = min(16 - 7;16 - 9;12 - 6) = 6 PZ = 6 - 6 - 0 = 0 Vorgang 2 Dauer = 5 FA = 0 (per Definition) SE = min(16 - 9; 12 - 6) = 6 PZ = 6 - 5 - 0 = 1 Vorgang 3 Dauer = 7 FA = max(0 + 6) = 6 SE = min(24 - 5; 24 - 8) = 16 PZ = 16 - 7 - 6 = 3 Vorgang 4 Dauer = 9 FA = max(6 + 0; 5 + 0) = 6 SE = min(24 - 8) = 16 PZ = 16 - 9 - 6 = 1 Vorgang 5 Dauer = 6 FA = max(6 + 0; 5 + 0) = 6 SE = min(16 - 4; 24 - 11) = 12 PZ = 12 - 6 - 6 = 0 Vorgang 6 Dauer = 4 FA = max(6 + 6) = 12 SE = min(24 - 5; 24 - 8) = 16 PZ = 16 - 12 - 4 = 0 Aufgabe 2b)

11. Aufgabe 2b) • Vorgang 7 • Dauer = 11 • FA = max(6 + 6) = 12 • SE = max(12 + 11; 16 + 5; 16 + 8) = 24 • PZ = 24 - 12 - 11 = 1 • Vorgang 8 • Dauer = 5 • FA = max(7 + 6; 9 + 6; 4 + 12) = 16 • SE = max(12 + 11; 16 + 5; 16 + 8) = 24 • PZ = 24 - 16 - 5 = 3 • Vorgang 9 • Dauer = 8 • FA = max(7 + 6; 9 + 6; 4 + 12) = 16 • SE = max(12 + 11; 16 + 5; 16 + 8) = 24 • PZ = 24 - 16 - 8 = 0

12. Aufgabe 2c) • Für das Projekt steht kurzfristig ein weiterer Mitarbeiter zur Verfügung. Dieser Mitarbeiter darf ausnahmsweise als zweite Ressource für beliebige Vorgänge eingesetzt werden. Als zusätzliche Einschränkung sei angenommen, dass dieser Mitarbeiter einem Vorgang entweder ganz oder gar nicht zugeordnet, d.h. nicht überlastet werden darf. Wie lässt sich die Projektdauer minimieren, wenn die sonstigen Zuordnungen von Ressourcen zu Vorgängen bestehen bleiben? Welche Auswirkungen hat dies auf den kritischen Pfad und den Projektendtermin?

13. Aufgabe 2c) • Höchstes Minimierungspotenzial befindet sich auf dem kritischen Pfad • Neue Ressource sukzessive den Vorgängen zuordnen • kritischer Pfad ändert sich nach jeder Zuordnung • nach jeder Zuordnung neu über die nächste Zuordnung entscheiden • neuen Mitarbeiter den Vorgängen 1, 5 und 9 zuordnen • Vorgang 7 auch möglich, ändert den Endtermin aber nicht • Neue kritische Pfade • Vorgänge 2, 4 und 8 • Vorgänge 2, 5 und 7 (falls Vorgang 7 ohne neuen Mitarbeiter) • Frühester Endtermin: 06. Dezember 2007

14. Aufgabe 2c) • vorher: • nachher:

15. Aufgabe 3 • Das fiktive Geldinstitut Bank365 beauftragt Sie mit der Entwicklung eines Prototypen zur Verwaltung ihrer Bestandsdaten. Das Softwaresystem soll die grundlegenden Funktionalitäten zur Verfügung stellen, die von einer Bankensoftware erwartet werden: Kunden und deren Konten sollen verwaltet sowie deren Kontobewegungen aufgezeichnet werden. Als Teil ihres ausgeklügelten Geschäftsmodells will die Bank ihre Konten darüber hinaus in Unter- bzw. Oberkonten strukturieren können, wobei die Tiefe dieser Struktur nicht begrenzt sein soll.

16. Aufgabe 3a) • Erstellen Sie für das beschriebene Szenario ein UML Klassendiagramm. Ordnen Sie dabei die folgenden Methoden sinnvoll einer von Ihnen modellierten Klasse zu: • void überweisen(String ziel, double betrag) • void einzahlen(double betrag) • void abheben(double betrag)

17. Aufgabe 3a) • benötigte Klassen, Attribute und Methoden • Kunde • Attribute: Name, Vorname, Geburtstag, Anschrift, ... • Methoden: berechneAlter() • Bank • Attribute: - • Methoden: abheben(), erzeugeKonto(), überweisen() • Konto • Attribute: kontonummer, kontostand, letzterKontoauszug • Methoden: abheben(), einzahlen(), überweisen(), kontoauszugDrucken() • Kontobewegung • Attribute: betrag, datum, kommentar • Methoden: -

18. Aufgabe 3a) • Konten sollen in Ober- und Unterkonten strukturiert werden können • Assoziation der Klasse Konto zu sich selbst • reflexive Assoziation bzw. Hierarchie • Kardinalitäten • ein Konto hat 0..1 Oberkonten und 0..* Unterkonten • Kontobewegungen sind Teil eines Kontos • Komposition (starke Aggregation) • jede Kontobewegung gehört zu genau einem Konto • mit dem Konto sollen auch alle Kontobewegungen gelöscht werden • Kardinalitäten • eine Kontobewegung gehört zu genau einem Konto, ein Konto kann beliebig viele Kontobewegungen besitzen

19. Aufgabe 3a)

20. Aufgabe 3a) • Klasse Bank365 nicht modelliert • wer verwaltet sonst Kunden und Konten? • Oberklasse Konto, Unterklassen Ober- und Unterkonto • wenig sinnvoll, da sich Ober- und Unterkonto nicht unterscheiden • Kontobewegung als String-Attribut • nicht sehr elegant, da String-Arithmetik notwendig • nicht objektorientiert • Komposition zwischen Konto und Kontobewegung • nicht unbedingt notwendig, stellt den Sachverhalt aber präziser dar • Wichtig dabei nur: Konsistenz!

21. Aufgabe 3b) • Erstellen Sie für die folgenden Anwendungsfälle jeweils ein UML Sequenzdiagramm: • Überweisen von 100 Euro auf das Konto 200 300. • Abheben von 500 Euro vom eigenen Konto. • Ausdrucken aller Kontobewegungen, die seit dem letzten Ausdruck stattgefunden haben. Gehen Sie bei der Bearbeitung der Aufgabe davon aus, dass sämtliche Aktionen ohne Fehler durchgeführt werden können. Ergänzen Sie gegebenenfalls fehlende Attribute und/oder Methoden in Ihrem Klassendiagramm.

22. Aufgabe 3b) • Sequenzdiagramm • Veranschaulichung von zeitlichen Vorgängen • Nachrichten, Antworten, beteiligte Objekte • dokumentieren Kommunikations- und Interaktionsprozesse • sehr implementierungsnah • Nachricht = Methoden- bzw. Funktionsaufruf • Antwort = Rückgabewert (evtl. void) • wichtigste Frage: Woher kennen sich Objekte? (Konsistenz) • selbst erzeugtes Objekt (<<erzeuge>>) • Objekt einer Nachbarklasse (Assoziation) • ermitteltes Objekt (Rückgabewert von Methoden)

23. Aufgabe 3b) • Überweisen von 100 Euro auf das Konto 200 300.

24. Aufgabe 3b) • Abheben von 500 Euro vom eigenen Konto.

25. Aufgabe 3b) • Ausdrucken aller Kontobewegungen, die seit dem letzten Ausdruck stattgefunden haben.

26. Aufgabe 3b) • häufige Fehler • Inkonsistenzen zwischen Klassen- und Sequenzdiagramm • Objekte schicken sich Nachrichten, obwohl sich diese nicht kennen • Sequenzdiagramm verwendet Objekte, die im Klassendiagramm nicht modelliert wurden • Kommunikation zwischen den Objekten zu simpel dargestellt • überweisen verlangt mehr als eine Nachricht • erzeugen von Kontobewegungen nicht modelliert • syntaktische Fehler im Sequenzdiagramm • Lebenslinien • Aktivitätsbalken • löschen von Objekten

27. Literatur • R. Holert: Microsoft Office Project 2003. Das Profibuch. Microsoft Press, 2004. • H. Balzert: Lehrbuch der Software-Technik. Software Entwicklung. Spektrum Akademischer Verlag, 2000. • Klassendiagramme: S. 163ff • Assoziationen und Kardinalitäten: S. 186ff • Aggregation und Komposition: S. 194ff • Sequenzdiagramme: S. 209ff