Vorlesung Software Engineering I

Präsentation zum Thema: "Vorlesung Software Engineering I"—  Präsentation transkript:

1 Vorlesung Software Engineering I
Dynamische Basiskonzepte 2 Kontrollstrukturen Aktivitätsdiagramme Sequenzdiagramme Dynamische Basiskonzepte 2 Kontrollstrukturen, Aktivitätsdiagramme, Prozessdiagramme Software Engineering I VE 11: Dynamische Basiskonzepte 2 Version

2 Systemsichten und Modellierung
Statik Funktionen Daten Datenstrukturen Architektur Dynamik Kontrollstrukturen Zustände Prozesse Zeitliches Verhalten Logik Abhängigkeiten Entscheidungstabellen Mathematik Regeln Beschreiben die feste Struktur des Systems, die sich während der Laufzeit nicht ändert. Beschreiben das Verhalten und die Veränderungen während der Laufzeit. Beschreiben die Programmfunktion logisch und mathematisch Software Engineering I VE 11: Dynamische Basiskonzepte 2 Version

3 Modellierung von Dynamik
Beschreibung von Abläufen Algorithmische Modelle Zustandsmodelle Aktionsstrukturen Software Engineering I VE 11: Dynamische Basiskonzepte 2 Version

4 Algorithmisches Problemlösen
Zerlegung des vorgegebenen Problems in Teilprobleme und die Beziehungen zwischen diesen Teilproblemen ( Schnittstellen) Wiederholung von Schritt 1, angewendet auf die Teilprobleme, bis man „kleinste“ Teilprobleme hat, die ohne weitere Zerlegung gelöst werden können. Zur Lösung dieser kleinsten Teilprobleme sind nur eine geringe Zahl unterschiedlicher Grundstrukturen nötig. Zusammensetzung der Teilproblemlösungen führt zur Lösung des Ausgangsproblems Diese Vorgehensweise wird oft Strukturierte Programmentwicklung oder Top – Down – Entwicklung Prinzip der schrittweisen Verfeinerung genannt. Software Engineering I VE 11: Dynamische Basiskonzepte 2 Version

5 Strukturierte Programmentwicklung
…resultiert in folgendermaßen aufgebauten Programmen (siehe auch SA/SD): H A U P T P R O G R A M M Daten Code Prozedur 1 Prozedur 2 Prozedur 3 Daten 2 Daten 3 Daten 4 Daten 5 Daten 1 Software Engineering I VE 11: Dynamische Basiskonzepte 2 Version

6 Modellierung von Algorithmen
Verwendung von Kontrollflussdiagramm Aktivitätsdiagramm Struktogramm „Kontrollflussgraphen“  Balzert S.228ff Programmablaufpläne (PAPs), auch Flussdiagramme genannt, genormt in DIN66001 Aktivitätsdiagramm, genormt in der UML: Fluss-Notation vs. Knoten-Notation Struktogramm (Nassi-Shneiderman-Diagramm), genormt in DIN66261. Information technology - Program constructs and conventions for their representation (ISO/IEC 8631:1989); German version EN 28631:1993 EN28631 Software Engineering I VE 11: Dynamische Basiskonzepte 2 Version

7 Struktogramme: Grundstrukturen I
... Einfache Anweisung ... Sequenz von Anweisungen ... Prozeduraufruf Bool. Ausdruck wahr falsch Einseitige Bedingungsanweisung IF Boolscher Ausdruck { ... } Bool. Ausdruck wahr falsch Zweiseitige Bedingungsanweisung IF Boolscher Ausdruck { ... } ELSE Default: Sequentiell Bedingt: Eine von 2 Anweisungen wird ausgeführt, je nach Bedingung Wiederholt: Eine Gruppe von Answeisungen wird je nach Bedingung wiederholt ausgeführt Software Engineering I VE 11: Dynamische Basiskonzepte 2 Version

8 Struktogramme: Grundstrukturen II
Mehrseitige Bedingungsanweisung Ausdruck w1 w2 w3 SWITCH Ausdruck { case w1: .... case w2: .... case w3: .... } Solange <boolscher Ausdruck> Wiederholung mit Anfangsbedingung wdh. WHILE (bool. Ausdruck) { ... } bis <boolscher Ausdruck> Wiederholung mit Endbedingung wdh. DO { ... } WHILE (bool. Ausdruck) Von ... bis ... Wiederholung mit Zähler wdh. FOR (i = 1; i < 3, i = i+1) { ... } Software Engineering I VE 11: Dynamische Basiskonzepte 2 Version

9 Struktogramme: Bewertung
Struktogramme bzw. Nassi-Shneiderman-Diagramme stellen den Ablauf eines Programms bzw. einer Funktion dar. Bei Betrachtung von einfacheren Problemen sind Struktogramme oft überdimensioniert, in der Regel reicht hier meist Pseudocode. Bei komplexen Problemen sind Struktogramme schnell unübersichtlich und schwierig wartbar.  Struktogramme sind eher geeignet für die formale Beschreibung von Algorithmen als zur Modellierung im Entwicklungszyklus. Software Engineering I VE 11: Dynamische Basiskonzepte 2 Version

10 UML2: Taxonomie der Diagrammarten
Verhaltensdiagramme Diagrammübersicht: Software Engineering I VE 11: Dynamische Basiskonzepte 2 Version

11 UML2: Verhaltensdiagramme
Anwendungsfalldiagramm (Use Case Diagram) (stellt Beziehungen zwischen Akteuren und Anwendungsfällen dar) Aktivitätsdiagramm (Activity Diagram) (beschreibt Abläufe, die aus einzelnen Aktivitäten bestehen) Zustandsdiagramm (Statechart Diagram) (beschreibt endliche Zustandsautomaten für ein Objekt oder System) Sequenzdiagramm (Sequence Diagram) (wichtigstes Interaktionsdiagramm: beschreibt den zeitlichen Ablauf von Nachrichten zwischen Objekten) Kommunikationsdiagramm (Communication Diagram, ehem. Kollaborationsdiagramm) (Interaktionsdiagramm, zeigt Beziehungen und Interaktionen zwischen Objekten) Zeitverlaufsdiagramm (Timing Diagram) (Interaktionsdiagramm mit Zeitverlaufskurven von Zuständen) Interaktionsübersichtsdiagramm (Interaction Overview Diagram) (Interaktionsdiagramm zur Übersicht über Abfolgen von Interaktionen, ähnlich Aktivitätsdiagramm) Software Engineering I VE 11: Dynamische Basiskonzepte 2 Version

12 Beispiel Aktivitätsdiagramm (Spezifikation eines Anwendungfalls)
Informale Anforderungsbeschreibung: Wenn im Online-Shop eine Bestellung eintrifft, wird jede Bestellposition überprüft, um zu sehen, ob der Lagerbestand reicht. Falls das so ist, werden die Waren der Bestellung zugeordnet. Wenn durch diese Zuordnung der minimale Lagerbestand unterschritten wird, dann wird eine Nachbestellung veranlaßt. Währenddessen wird die Zahlung überprüft. Wenn die Zahlung OK ist und genügend Waren vorhanden sind, wird geliefert. Wenn für die Lieferung auf nachzubestellende Waren gewartet werden muss, bleibt die Bestellung offen. Wenn die Zahlung nicht OK ist, wird die Bestellung abgewiesen. Identifikation der Akteure: Besteller = Kunde Identifikation der Anwendungsfälle: Bestellung Zahlung Lieferung Kunde Bestelleingang Online-Shop Zahlung Lieferung Software Engineering I VE 11: Dynamische Basiskonzepte 2 Version

13 Beispiel Aktivitätsdiagramm (Beispiel zur Spezifikation des Anwendungsfalles „Bestelleingang“)
Bestellung erhalten Prüfe Zahlung Prüfe Verfügbarkeit einer Bestellposition abweisen Zuordnung zur Nachbestellungs- artikel Veranlasse Lieferung [OK] * Für jede Bestellposition [verfügbar] [nachzubest.] [Waren für alle Bestellpositionen verfügbar und Zahlung OK] Erhalte Identifiziere ausstehende, bestellte Artikel Ordere ankommende Waren den Bestellungen zu Für jeden identifizierten, bestellten Artikel Rest ins Lager Alle offenen Bestellungen berücksichtigt Software Engineering I VE 11: Dynamische Basiskonzepte 2 Version

14 Beispiel Aktivitätsdiagramm (Beispiel zur vertikalen Abgrenzung)
Finanzen Bestellungsverarbeitung Erhalte Lieferung Bestellung erhalten Lager- Manager Identifiziere ausstehende, bestellte Artikel Für jede Bestell- position * Für jeden identifizierten, bestellten Artikel * [nicht OK] Prüfe Zahlung Prüfe Verfügbarkeit einer Bestellposition Waren- wirtschaft Ordere ankommende Waren den Bestellungen zu [verfügbar] Bestellung abweisen Zuordnung zur Bestellung [OK] Alle offenen Bestellungen berücksichtigt Nachbestellungs- artikel [nachzubest.] [Waren für alle Bestellpositionen verfügbar und Zahlung OK] Rest ins Lager Veranlasse Lieferung Software Engineering I VE 11: Dynamische Basiskonzepte 2 Version

15 Beispiel Aktivitätsdiagramm (Strukturierung)
Aktivitäten können verfeinert werden (passende Abstraktionsebenen für unterschiedliche Zwecke) Beispiel: Verfeinerung der Aktivität „prüfe Zahlung“ Prüfe Zahlung Bestimme Zahlungstyp Prüfe Scheck Kreditkarte Normaler Kunde? Bestellwert > 100 Euro? Vorkasse anfordern Kreditwürdigkeit prüfen Eröffne Kundenkonto Zahlungsgeschichte Rechnung Nicht OK OK [nein] [Ja] [OK] [nicht OK] [nicht erhalten] Software Engineering I VE 11: Dynamische Basiskonzepte 2 Version

16 Systemanalyse und -design mit der UML
UML Design Pattern: Wie kann man die UML anwenden ? Software Engineering I VE 11: Dynamische Basiskonzepte 2 Version

17 Übung UML Design Pattern
Praxisprojekt Erstellen Sie Ihre Systemmodellierung mit einem Design Pattern in UML Benutzen Sie dazu ein CASE-Tool Starten Sie mit einem Use-Case-Diagramm Fügen Sie jedem Use-Case ein Aktivitätsdiagramm hinzu Extrahieren Sie die Objekte des Systems Modellieren Sie die Objektinteraktionen mit Sequenzdiagrammen Leiten Sie aus den Objekten Klassen ab Modellieren Sie die Systemarchitektur mit einem Component/Deployment Diagram Fügen Sie jeder Komponente/Klasse ein State Diagramm hinzu etc. Software Engineering I VE 11: Dynamische Basiskonzepte 2 Version

18 Übung Sequenzdiagramm
Ziel: Sequenzdiagramm mit Erweiterungen erstellen Gegeben ist das folgende Java-Programm. Die Operation doMore() wird von einem Objekt mit der Bezeichnung einObjekt aktiviert wird. class ClassB { public void doSomething { } public void work (int w) { ... } } class ClassC { public void doSomethingElse() { ... } class ClassA { private ClassB b; private ClassC c; public void doLess(int param) { b.work(param);} public int calculateP(int param) { int p = 2 * param; return p;} public void doMore(int data) { b = new ClassB();c = new ClassC(); for (int j = 1; j <= 5; j++) doLess (j); int p = caIculateP (data); if (p <1){ b.doSomething();b.work(p);} else c.doSomethingElse(); } Die Operation a.doMore() wird von einem Objekt mit der Bezeichnung einObjekt aktiviert wird. Zuerst werden die beiden Objekte bzw. Kommunikationspartner b:ClassB und c:ClassC erzeugt. In der Schleife nimmt die Laufvariable j nacheinander die Werte 1 bis 5 an und ruft bei jedem Durchgang die Operation a.doLess(j) auf, die wiederum die Operation b.work(j) aktiviert. Anschließend wird die Operation calculateP(data) auf das Objekt von A angewendet. In Abhängigkeit des errechneten Werts von p werden entweder die Operationen b.doSomethingElse() und b.work(p) oder die Operation c.doSomethingElse() aufgerufen. Software Engineering I VE 11: Dynamische Basiskonzepte 2 Version