2. Übung zu software engineering

Philipp Ciechanowicz

2. Übung zu Software Engineering

WS 2007/2008

2

Übung zu Software Engineering im WS 2007/2008


Organisatorisches

„[SE]“ als Teil des E-Mail-Betreffsnicht: SE, Software Engineering, Blatt 01 etc.

Abgabe: EINE pdf-Datei, spätestens 11:30 Uhrnicht: xls, doc, rar oder zip

3



Aufgabe 2

Die Durchführung eines Großprojekts sei in die folgenden Vorgänge untergliedert:

Nummer

Vorgänger

Dauer

1 - 6

2 - 5

3 1 7

4 1;2 9

5 1;2 6

6 5 4

7 5 11

8 3;4;6 5

9 3;4;6 8

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üpfensiehe Tabelle

Vorgangsdauer eintragensiehe Tabelle

Ressourcen eintragen und zuordnen4 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 2007Dauer: 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)

Netzplantechnikfrühester Anfang

Vorwärtsterminierung

FAi = max{FAj + Dauerj mit j ∈ Vorgänger von Vorgang i}

FAStartvorgang = 0

spätestes EndeRückwärtsterminierung

SEi = min{FAj - Dauerj mit j ∈ Nachfolger von Vorgang i}

SEEndvorgang = max{FAj + Dauerj mit j ∈ Vorgänger von Endvorgang}

PufferzeitPZ = 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)

1

6 9

82

5

4

9

3

7

5

6

8

5

6

4

7

11

0

1

6

6 12

24

3 3

1

24

0

0

6

01

06

16 16 24

12

16

0

16

126

16

Nr.SEPZD

FA

10



Aufgabe 2b)

Vorgang 1Dauer = 6

FA = 0 (per Definition)

SE = min(16 - 7;16 - 9;12 - 6) = 6

PZ = 6 - 6 - 0 = 0

Vorgang 2Dauer = 5

FA = 0 (per Definition)

SE = min(16 - 9; 12 - 6) = 6

PZ = 6 - 5 - 0 = 1

Vorgang 3Dauer = 7

FA = max(0 + 6) = 6

SE = min(24 - 5; 24 - 8) = 16

PZ = 16 - 7 - 6 = 3

Vorgang 4Dauer = 9

FA = max(6 + 0; 5 + 0) = 6

SE = min(24 - 8) = 16

PZ = 16 - 9 - 6 = 1

Vorgang 5Dauer = 6

FA = max(6 + 0; 5 + 0) = 6

SE = min(16 - 4; 24 - 11) = 12

PZ = 12 - 6 - 6 = 0

Vorgang 6Dauer = 4

FA = max(6 + 6) = 12

SE = min(24 - 5; 24 - 8) = 16

PZ = 16 - 12 - 4 = 0

11



Aufgabe 2b)

Vorgang 7Dauer = 11FA = max(6 + 6) = 12SE = max(12 + 11; 16 + 5; 16 + 8) = 24PZ = 24 - 12 - 11 = 1

Vorgang 8Dauer = 5FA = max(7 + 6; 9 + 6; 4 + 12) = 16SE = max(12 + 11; 16 + 5; 16 + 8) = 24PZ = 24 - 16 - 5 = 3

Vorgang 9Dauer = 8FA = max(7 + 6; 9 + 6; 4 + 12) = 16SE = max(12 + 11; 16 + 5; 16 + 8) = 24PZ = 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 zuordnenkritischer 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 zuordnenVorgang 7 auch möglich, ändert den Endtermin aber nicht

Neue kritische PfadeVorgä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 MethodenKunde

Attribute: Name, Vorname, Geburtstag, Anschrift, ...

Methoden: berechneAlter()

BankAttribute: -

Methoden: abheben(), erzeugeKonto(), überweisen()

KontoAttribute: kontonummer, kontostand, letzterKontoauszug

Methoden: abheben(), einzahlen(), überweisen(), kontoauszugDrucken()

KontobewegungAttribute: betrag, datum, kommentar

Methoden: -

18



Aufgabe 3a)

Konten sollen in Ober- und Unterkonten strukturiert werden können

Assoziation der Klasse Konto zu sich selbstreflexive Assoziation bzw. Hierarchie

Kardinalitätenein Konto hat 0..1 Oberkonten und 0..* Unterkonten

Kontobewegungen sind Teil eines KontosKomposition (starke Aggregation)

jede Kontobewegung gehört zu genau einem Konto

mit dem Konto sollen auch alle Kontobewegungen gelöscht werden

Kardinalitäteneine Kontobewegung gehört zu genau einem Konto, ein Konto kann beliebig viele Kontobewegungen besitzen

19



Aufgabe 3a)

20



Aufgabe 3a)

Klasse Bank365 nicht modelliertwer verwaltet sonst Kunden und Konten?

Oberklasse Konto, Unterklassen Ober- und Unterkontowenig sinnvoll, da sich Ober- und Unterkonto nicht unterscheiden

Kontobewegung als String-Attributnicht sehr elegant, da String-Arithmetik notwendig

nicht objektorientiert

Komposition zwischen Konto und Kontobewegungnicht 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)

SequenzdiagrammVeranschaulichung von zeitlichen Vorgängen

Nachrichten, Antworten, beteiligte Objekte

dokumentieren Kommunikations- und Interaktionsprozesse

sehr implementierungsnahNachricht = 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 FehlerInkonsistenzen 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 SequenzdiagrammLebenslinien

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

2. Übung zu software engineering

Documents