Organisatorisches „[SE]“ als Teil des -Betreffs

Präsentation zum Thema: "Organisatorisches „[SE]“ als Teil des -Betreffs"—  Präsentation transkript:

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

1 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 2 HiWis für die Korrektur der Übungszettel

2 Aufgabe 2 Die Durchführung eines Großprojekts sei in die folgenden Vorgänge untergliedert: Nummer Vorgänger Dauer 1 - 6 2 5 3 7 4 1;2 9 11 8 3;4;6

3 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?

4 Aufgabe 2a) Vorgänge eingeben und verknüpfen Vorgangsdauer eintragen
siehe Tabelle Vorgangsdauer eintragen 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)

5 Aufgabe 2a)

6 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?

7 Aufgabe 2b) Netzplantechnik frühester Anfang spätestes Ende Pufferzeit
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

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

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

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

11 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?

12 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

13 Aufgabe 2c) vorher: nachher:

14 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.

15 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)

16 Aufgabe 3a) benötigte Klassen, Attribute und Methoden Kunde Bank Konto
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: -

17 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 eine Kontobewegung gehört zu genau einem Konto, ein Konto kann beliebig viele Kontobewegungen besitzen

18 Aufgabe 3a)

19 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!

20 Aufgabe 3b) Erstellen Sie für die folgenden Anwendungsfälle jeweils ein UML Sequenzdiagramm: Überweisen von 100 Euro auf das Konto 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.

21 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)

22 Aufgabe 3b) Überweisen von 100 Euro auf das Konto

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

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

25 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

26 Literatur R. Holert: Microsoft Office Project 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