Software Engineering I

1
Vorlesung Software Engineering I

• Dynamische Basiskonzepte 2
• Kontrollstrukturen
• Aktivitätsdiagramme
• Sequenzdiagramme

2
Systemsichten und Modellierung
Beschreiben das Verhalten und die Veränderungen
während der Laufzeit.
Beschreiben die feste Struktur des Systems, die
sich während der Laufzeit nicht ändert.
Beschreiben die Programmfunktion logisch und
mathematisch
3
Modellierung von Dynamik
Beschreibung von Abläufen
Algorithmische Modelle
Zustandsmodelle
Aktionsstrukturen
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 oder Prinzip der schrittweisen
Verfeinerung genannt.
5
Strukturierte Programmentwicklung
resultiert in folgendermaßen aufgebauten
Programmen (siehe auch SA/SD)
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.
7
Struktogramme Grundstrukturen I
IF Boolscher Ausdruck ...
IF Boolscher Ausdruck ... ELSE
...
8
Struktogramme Grundstrukturen II
SWITCH Ausdruck case w1 .... case w2
.... case w3 ....
WHILE (bool. Ausdruck) ...
DO ... WHILE (bool. Ausdruck)
FOR (i 1 i lt 3, i i1) ...
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.

10
UML2 Taxonomie der Diagrammarten
Verhaltensdiagramme

• Diagrammübersicht http//www.oose.de/uml
• http//www.uml-diagrams.org/uml-24-diagrams.html

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)(Interaktionsdiagram
  m, zeigt Beziehungen und Interaktionen zwischen
  Objekten)
• Zeitverlaufsdiagramm (Timing Diagram)(Interaktion
  sdiagramm mit Zeitverlaufskurven von Zuständen)
• Interaktionsübersichtsdiagramm (Interaction
  Overview Diagram)(Interaktionsdiagramm zur
  Übersicht über Abfolgen von Interaktionen,
  ähnlich Aktivitätsdiagramm)

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

13
Beispiel Aktivitätsdiagramm(Beispiel zur
Spezifikation des Anwendungsfalles
Bestelleingang)
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
Waren- wirtschaft
Prüfe Zahlung
Prüfe Verfügbarkeit einer Bestellposition
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
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
16
Systemanalyse und -design mit der UML

• UML Design Pattern
• Wie kann man die UML anwenden ?

http//www.microconsult.de/includes/downloads/kurz
vortraege/ESE2010_von-der-idee-zum-modell.zip htt
p//www.microconsult.de/includes/downloads/kurzvor
traege/UML-Robotersteuerung.pdf
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.

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 lt 5 j)
  doLess (j)
• 
  int p caIculateP (data)
• 
  if (p lt1) b.doSomething()b.wor
  k(p)
• 
  else c.doSomethingElse()