ralf-oliver mevius inf. (21) - programming exercises bachelor informatik (21) programming exercises...

161
Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Upload: liselotte-lausch

Post on 06-Apr-2015

135 views

Category:

Documents


8 download

TRANSCRIPT

Page 1: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

Bachelor Informatik (21)

Programming Exercises

Teil 2

Page 2: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

Allgemeines- Teilgebiete der Softwaretechnik

Kernprozesse

1. Planung

2. Analyse

3. Entwurf (!!!)

2

Page 3: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

Allgemeines- Teilgebiete der Softwaretechnik

weitere Kernprozesse

4. Programmierung

5. Validierung und Verifikation

3

Page 4: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

Allgemeines- Teilgebiete der Softwaretechnik

Unterstützungsprozesse

6. Anforderungsmanagement

7. Projektmanagement

8. Qualitätsmanagement

9. Konfigurationsmanagement

10. Dokumentation

4

Page 5: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung

Lastenheft (Anforderungsdefinition)

Pflichtenheft (mit technischen Ansätzen verfeinertes Lastenheft)

Anm.: in der Ausarbeitung synonym „Planung“ verwenden

5

Page 6: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Lastenheft

Ein Lastenheft (auch Anforderungs-spezifikation, Kundenspezifikation oder Requirements Specification) beschreibt die unmittelbaren Anforderungen durch den Besteller eines Produktes.

6

Page 7: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Lastenheft

Es enthält jedoch lediglich im Rahmen eines Werkvertrages oder Werkliefervertrages und der dazu gehörenden formellen Abnahme die nachprüfbaren Leistungen und Lieferungen.

7

Page 8: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Lastenheft

Es kann nicht die Erwartungen und Wünsche an ein geplantes Produkt enthalten.

8

Page 9: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Lastenheft

Diese abstrakten Merkmale wären, wenn nicht durch eine Prüfung zu belegen, kaum durch denjenigen, der das Produkt herstellen soll, so einzuschätzen, dass sie zielführend berücksichtigt werden könnten.

9

Page 10: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Lastenheft

Gemäß DIN 69905 (Begriffe der Projektabwicklung) beschreibt das Lastenheft die

„vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages“.

10

Page 11: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Lastenheft

Das Lastenheft beschreibt in der Regel also, was und wofür etwas gemacht werden soll (Fachkonzept).

Die Adressaten des Lastenhefts sind der (externe oder firmeninterne) Auftraggeber sowie die Auftragnehmer.

11

Page 12: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Lastenheft

In der Softwaretechnik ist das Lastenheft das Ergebnis der Planungsphase und wird in der Regel einvernehmlich von den Bestellern und den Entwicklern als Vorstufe des Pflichtenhefts überarbeitet.

12

Page 13: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Lastenheft

Um ein Lastenheft übersichtlich zu halten, wird es vorzugsweise in knapp orientierendem Text gefasst und mit Detaillierungen beispielsweise in tabellarischer Form, mit Zeichnungen oder Grafiken ergänzt.

Es gibt dazu auch formalisierende Ansätze, wie die Beschreibungssprache UML.

13

Page 14: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Lastenheft

Das Pflichtenheft beschreibt dann, was und womit etwas realisiert werden soll.

Dabei können gewöhnlich jeder Anforderung des Lastenhefts eine oder mehrere Leistungen des Pflichtenheftes zugeordnet werden.

So wird auch die Reihenfolge der beiden Dokumente im Entwicklungsprozess deutlich: Die Anforderungen (requirements) werden durch Leistungen (features) erfüllt.

14

Page 15: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Lastenheft

Nach DIN 69905 enthält das Pflichtenheft die „vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenheftes“.

15

Page 16: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Lastenheft

Je nach Einsatzgebiet und Branche können sich Lastenhefte in Aufbau und Inhalt stark unterscheiden. Auch werden in der Praxis die Begriffe Lastenheft, Pflichtenheft und Spezifikation oft nicht klar gegeneinander abgegrenzt oder gar synonym verwendet.

16

Page 17: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Lastenheft

Die unscharfe Verwendung der Begriffe Lastenheft und Pflichtenheft sowie die fehlende Trennung technischer Information und operationeller Absichten ist häufig Ursache für Missverständnisse.

17

Page 18: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Lastenheft

Auf einen Kaufvertrag nach BGB §433 oder einen rechtlich gleichgestellten Liefervertrag sind die Kriterien eines Lastenheftes in der Regel nicht anzuwenden, da die Lieferungen im Kaufvertrag von einer durch den Lieferanten einseitig vorgegebenen Spezifikation in der Art und von der durch den Besteller einseitig vorgegebenen Liefermenge bestimmt werden.

18

Page 19: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Lastenheft

Auf einen Dienstvertrag sind die Kriterien eines Lastenheftes in der Regel nicht anzuwenden, da die Leistungen im Dienstvertrag nicht einer formellen Abnahme unterzogen werden.

19

Page 20: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Pflichtenheft Das Pflichtenheft, auch

Technische Richtlinien,Fachspezifikation, fachliche Spezifikation,Fachfeinkonzept, Sollkonzept, Funktionelle Spezifikation, oder Feature Specification

beschreibt die unmittelbaren Anforderungen durch den Besteller in der Interpretation des Herstellers für sein Produkt.

20

Page 21: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Pflichtenheft

Es enthält jedoch lediglich im Rahmen eines Werkvertrages oder Werkliefervertrages und der dazu gehörenden formellen Abnahme die prüfbaren Leistungen und Lieferungen.

21

Page 22: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Pflichtenheft

Es kann, genauso wie das Lastenheft, nicht die Erwartungen und Wünsche an ein geplantes Produkt enthalten.

22

Page 23: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Pflichtenheft

Solche abstrakten Merkmale wären, wenn nicht durch eine Prüfung oder Messung zu belegen, durch denjenigen, der das Produkt herstellt, auch eher nicht so einzuschätzen, dass sie zielführend während der Bearbeitung des Werkes und final bei der Abnahme berücksichtigt werden könnten.

23

Page 24: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Pflichtenheft

Das Pflichtenheft ist die vertraglich bindende, detaillierte Beschreibung eines zu erstellenden Werkes, zum Beispiel des Aufbaus einer technischen Anlage, der Konstruktion eines Werkzeugs oder auch der Erstellung eines Computerprogramms.

24

Page 25: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Pflichtenheft

Die dazu erforderliche Arbeit liegt allein in der Verantwortung des Herstellers oder Auftragnehmers, diese ist zunächst nicht der Einrede des Bestellers oder Auftraggebers unterworfen, es sei denn, beide arbeiten gemeinsam an dem zu erstellenden Werk.

25

Page 26: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Pflichtenheft

Laut DIN 69905 umfasst das Pflichtenheft die „vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts“.

26

Page 27: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Pflichtenheft

Die Inhalte des zuvor ausgearbeiteten Lastenhefts (auch grobes Pflichtenheft genannt) sind nun präzisiert, vollständig und nachvollziehbar sowie mit technischen Festlegungen der Betriebs- und Wartungsumgebung verknüpft.

27

Page 28: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Pflichtenheft

Das Pflichtenheft wird vom Auftragnehmer (Entwicklungsabteilung/-firma) formuliert und auf dessen Wunsch vom Auftraggeber bestätigt. Idealerweise sollten erst nach dieser Bestätigung die eigentlichen Entwicklungs-/Implementierungsarbeiten beginnen.

28

Page 29: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Pflichtenheft

Der Auftragnehmer hat einen durch den Vertrag bestimmten Anspruch auf solche Bestätigung (Mitwirkungspflicht nach §643 BGB).

29

Page 30: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Pflichtenheft

Im Gegensatz zum technischen Design (auch technische Spezifikation – Wie wird es umgesetzt?) beschreibt das Pflichtenheft die geplante technische Lösung – in unserem Beispiel die Software – als Black Box (Was wird umgesetzt?).

30

Page 31: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Pflichtenheft

Entsprechend enthält es in der Regel nicht die betriebliche Lösung der Aufgabenstellungen des Auftraggebers.

Schon gar nicht beschreibt es die (hier beim Softwarebeispiel) Implementierungsprobleme, sondern allenfalls die Schnittstellen, deren sorgfältige Beschreibung solche Probleme vermeiden soll.

31

Page 32: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Pflichtenheft

Es ist bewährte Praxis, bei der Erstellung eines Pflichtenheftes das Ein- und Ausschlussprinzip zu verwenden, d. h., konkrete Fälle explizit ein- oder auszuschließen.

32

Page 33: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

1. Planung - Pflichtenheft

Bei Lieferung der Software wird formell eine Abnahme vollzogen, die die Ausführung des Werkvertrages oder auch des Kaufvertrages beschließt.

Diese Abnahme wird häufig über einen Akzeptanztest ausgeführt, der feststellt, ob die Software die Forderungen des Pflichtenheftes in dem Verständnis des Bestellers erfüllt.

33

Page 34: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse

Anforderungsanalyse Auswertung Mock-up Prozessanalyse / Prozessmodell Systemanalyse Strukturierte Analyse (SA) Objektorientierte Analyse (OOA)

34

Page 35: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

Das ingenieurmäßige Erheben der Anforderungen (englisch requirements engineering) ist ein Teil des Software- und Systementwicklungsprozesses.

35

Page 36: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

Ziel ist es, die Anforderungen des Auftraggebers an das zu entwickelnde System (oft ein Anwendungsprogramm) zu ermitteln und zu verwalten.

36

Page 37: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

IEEE - Institute of Electrical and Electronics Engineers

Die Anforderungserhebung kann in Anforderungsaufnahme (requirements elicitation), Anforderungsanalyse (requirements analysis), Anforderungsspezifikation (requirements specification) und Anforderungsbewertung (requirements validation) unterteilt werden. Diese Schritte überlappen einander und werden oft auch mehrfach – iterativ – durchgeführt.

http://www.ieee.org/index.html

37

Page 38: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

SEI, Carnegie Mellon

Das Software Engineering Institute der Carnegie Mellon Universität unterscheidet in ihrem Capability Maturity Model Integration das Management von Anforderungen, und die Entwicklung der Anforderungen.

38

Page 39: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

Volere

In dem von den Robertsons entwickelten Vorgehensmodell existieren Anforderungsspezifikation, Stakeholder-Analyse, Bedarfsanalyse, Analyse der Priorisierung, und die Aufzeichnung der elementaren Anforderungen.

39

Page 40: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

Sammeln, Analysieren

40

Page 41: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

Beim Sammeln der Anforderungen (engl. elicitation) ist der Übersetzungsprozess zwischen Fachseite und Entwickler von besonderer Bedeutung.

41

Page 42: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

vollständig - alle Anforderungen des Kunden müssen explizit beschrieben sein, es darf keine impliziten Annahmen des Kunden über das zu entwickelnde System geben.

42

Page 43: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

eindeutig definiert / abgegrenzt - präzise Definitionen helfen, Missverständnisse zwischen Entwickler und Auftraggeber zu vermeiden.

43

Page 44: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

verständlich beschrieben - damit sowohl der Auftraggeber als auch der Entwickler mit vertretbarem Aufwand die gesamte Anforderung lesen und verstehen können.

44

Page 45: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

atomar - es darf nur eine Anforderung pro Abschnitt oder Satz beschrieben sein. Das Kriterium für ein "Atom" sollte die Entscheidbarkeit einer Anforderung sein.

45

Page 46: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

identifizierbar - jede Anforderung muss eindeutig identifizierbar sein (z. B. über eine Kennung oder Nummer).

46

Page 47: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

einheitlich dokumentiert - die Anforderungen und ihre Quellen sollten nicht in unterschiedlichen Dokumenten stehen oder unterschiedliche Strukturen haben.

47

Page 48: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

notwendig - gesetzliche Vorschriften sind unabdingbar.

48

Page 49: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

nachprüfbar - die Anforderungen sollten mit Abnahmekriterien verknüpft werden, damit bei der Abnahme geprüft werden kann, ob die Anforderungen erfüllt wurden (Ableitung von Testfällen aus den Abnahmekriterien).

49

Page 50: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

rück- und vorwärtsverfolgbar - damit einerseits erkennbar ist, ob jede Anforderung vollständig erfüllt wurde und andererseits für jede implementierte Funktionalität erkennbar ist, aus welcher Anforderung sie resultiert, also nicht Überflüssiges entwickelt wird.

50

Page 51: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

Konsistenz - Konsistenz beschreibt den Grad, in dem die definierten Anforderungen untereinander widerspruchsfrei sind.

51

Page 52: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

Das Ergebnis der Anforderungsaufnahme ist das Lastenheft.

52

Page 53: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

Strukturierung und Abstimmung

Nach der Erfassung muss eine Strukturierung und Klassifizierung der Anforderungen vorgenommen werden.

Damit erreicht man, dass die Anforderungen übersichtlicher werden.

Dies wiederum erhöht das Verständnis von den Beziehungen zwischen den Anforderungen.

53

Page 54: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

Kriterien sind hierbei:

abhängig - Anforderungen müssen daraufhin überprüft werden, ob sie sich nur gemeinsam realisieren lassen oder ob eine Anforderung die Voraussetzung für eine andere ist.

zusammengehörig - Anforderungen, die fachlich-logisch zusammengehören, sollten nicht allein realisiert werden.

rollenbezogen - jede Benutzergruppe hat ihre eigene Sicht auf die Anforderungen, die damit unterstützt werden soll.

54

Page 55: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

Weitere Strukturierungsmöglichkeiten sind

Funktionale und nichtfunktionale Anforderungen Fachlich motivierte (fachliche und technische) und

technisch motivierte (nur technische) Anforderungen.

55

Page 56: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

Die so strukturierten Anforderungen müssen dann zwischen Kunde und Entwickler abgestimmt werden.

Diese Abstimmung kann gegebenenfalls zu einem iterativen Prozess werden, der zur Verfeinerung der Anforderungen führt.

56

Page 57: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

Prüfung und Bewertung

57

Page 58: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

Nach der Strukturierung, zum Teil auch parallel dazu, erfolgt die Qualitätssicherung der Anforderungen nach diesen Qualitätsmerkmalen:

58

Page 59: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

korrekt - die Anforderungen müssen insbesondere widerspruchsfrei sein.

59

Page 60: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

machbar - die Anforderung muss realisierbar sein.

60

Page 61: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

notwendig - was nicht vom Auftraggeber gefordert wird, ist keine Anforderung.

61

Page 62: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

priorisiert - es muss erkennbar sein, welche Anforderungen am wichtigsten sind.

Ziel der Priorisierung ist es, häufig benötigte Funktionen vor den weniger häufig benötigten bereitzustellen.

Man erreicht es über eine Quantifizierung der Funktionszweige.

62

Page 63: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

nutzbar, nützlich - auch bei teilweiser Realisierung soll bereits ein produktives System entstehen.

63

Page 64: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

benutzerfreundlich - die Benutzerfreundlichkeit des Systems muss sichergestellt sein.

64

Page 65: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

Das Ergebnis der Prüfung stellt die Basis für das Pflichtenheft dar.

65

Page 66: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

Requirements Management RM

deutsch „Anforderungsmanagement“ umfasst Maßnahmen zur Steuerung, Kontrolle und Verwaltung von Anforderungen.

66

Page 67: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Anforderungsanalyse

Dazu gehört auch das verwalten von Änderungen der Requirements und deren Auswirkung auf abhängige Lieferergebnisse.

67

Page 68: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Auswertung

Auswertung (engl. evaluation als Beschreibung, Analyse und Bewertung) bezeichnet in der Informatik den Vorgang, der einem Ausdruck (eventuell in einem gegebenen Kontext von Variablenbindungen) einen Wert zuordnet.

68

Page 69: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Auswertung

Programmiersprachen sind nach ihrer Auswertungsstrategie unterscheidbar:

69

Page 70: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Auswertung

Bei strenger Auswertung oder strikter Auswertung (engl. eager bzw. strict evaluation) werden Ausdrücke sofort ausgewertet. Z. B. bei der Berechnung einer Funktion werden bei strikter Auswertung erst die Argumentausdrücke ausgewertet, bevor der Funktionsrumpf ausgewertet wird.

70

Page 71: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Auswertung

Dem gegenüber steht die Bedarfsauswertung oder verzögerte Auswertung (engl. lazy evaluation), bei der Ausdrücke erst ausgewertet werden, wenn deren Wert in einer Berechnung benötigt wird.

Dadurch lassen sich z. B. unendlich große Datenstrukturen (z. B. die Liste aller natürlicher Zahlen, die Liste aller Primzahlen, usw.) definieren und bestimmte Algorithmen vereinfachen sich.

Diese Datenstrukturen bezeichnet man als Ströme (engl. streams).

71

Page 72: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Auswertung

Manche Berechnungen lassen sich mit strenger Auswertung, andere mit Bedarfsauswertung effizienter ausführen.

72

Page 73: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Auswertung

Bei der Auswertung von Funktionen mit mehreren Argumenten, besteht ein weiterer Freiheitsgrad darin, in welcher Reihenfolge die Argumente ausgewertet werden.

In der Theoretischen Informatik (Lambda-Kalkül) wird formal gezeigt, dass die Reihenfolge der Auswertung keine Rolle spielt, was den berechneten Wert eines Ausdrucks angeht, so er denn ausgewertet werden kann; siehe auch Currying bzw. Schönfinkeln.

73

Page 74: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Auswertung

Die Anwendung der Funktion (bzw. Funktionsdefinition) auf ihre Argumente bezeichnet man auch als Applikation.

74

Page 75: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Auswertung

Eng verwandt mit dem Begriff der Auswertung ist der Begriff der Semantik, das ist eine Abbildung, die einem Programm (meistens ein Programmtext bzw. Quellcode) seine berechenbare Funktion zuordnet.

Dieses stimmt mit der umgangssprachlichen Deutung des Begriffs Semantik als Bedeutungszuordnung gut überein.

75

Page 76: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Mock-up

Ein Mock-up in der Softwareentwicklung bezeichnet einen rudimentären Wegwerfprototyp der Benutzeroberfläche einer zu erstellenden Software.

Mock-ups werden insbesondere in frühen Entwicklungsphasen eingesetzt, um Anforderungen an die Benutzeroberfläche in Zusammenarbeit mit Auftraggeber und Anwendern besser ermitteln zu können.

Es handelt sich meist um ein reines Grundgerüst der Bedienelemente ohne weitere Funktionalität.

76

Page 77: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Mock-up

Sogenannte Mock-Objekte werden beim Testen verwendet, was insbesondere beim Unit test genutzt wird.

Zu Beginn der Entwicklung werden sie als Platzhalter für noch nicht vorhandene Objekte eingesetzt, wenn die noch nicht vorhandenen Komponenten für das Testen eines anderen Moduls nötig sind (s. auch Test Driven Development).

77

Page 78: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Mock-up

In späteren Phasen kommen Mock-Objekte zur Anwendung, weil zum Beispiel die Initialisierung des (vorhandenen, funktionsfähigen) Objekts zu aufwendig oder in einer Testumgebung mangels Verbindung zu produktiven Backend-Systemen gar nicht möglich ist.

78

Page 79: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Mock-up

Ein weiterer häufiger Grund für den Einsatz eines Mock-Objektes ist ein nichtvorhersehbares Verhalten der eigentlichen Klasse, zum Beispiel die Rückgabe des aktuellen Wechselkurses oder aber Verhalten, das aufgrund des objektorientierten Prinzips der Kapselung vor dem Aufrufer der Methode abgeschirmt wird; dies ist bei neueren Umgebungen wie J2EE vor allem bei Containerfunktionen der Fall.

79

Page 80: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Prozessanalyse

Als Prozessanalyse bezeichnet man die systematische Untersuchung von Geschäftsprozessen (lat. procedere = voranschreiten) und die Zerlegung in seine Einzelteile, um Schwachstellen und Verbesserungspotentiale zu erkennen. (vgl. Oberbegriff Analyse)

80

Page 81: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Prozessanalyse

Hierdurch kann man Vereinheitlichungen in Standardprozessen erlangen und eine gruppenübergreifende Synchronisation erreichen.

81

Page 82: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Prozessanalyse

Besonders im Qualitätsmanagement ist es unabdingbar, bei auftretenden Fehlern möglichst schnell deren Ursache(n) zu entdecken und Abstellmaßnahmen einzuleiten.

Dieser kontinuierliche Verbesserungsprozess (KVP) trägt dazu bei, auch bei verwandten Prozessen schnell und effizient einzugreifen, da Teilprozesse ähnlich oder gleich sein können.

82

Page 83: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Prozessanalyse

Prozessorientiertes Denken und Handeln ist ein wichtiger Bestandteil der modernen Marktwirtschaft. Nur so kann man innerhalb eines kurzen Zeitraums flexibel agieren anstatt nur zu reagieren (Fehlervermeidung vor Fehlerbeseitigung).

Durch das vorausschauende Handeln können Probleme meist schon im Vorfeld gelöst werden.

83

Page 84: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Prozessanalyse

Die genaue Beschreibung von Prozessen ist hierbei genauso wichtig wie ihre ständige Pflege und Kontrolle.

Durch das Versehen von Prozessen mit Informationen wird darüber hinaus auch das Auffinden von Schlüsselindikatoren erleichtert, die das Bewerten eines Prozesses zulassen.

84

Page 85: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Prozessanalyse

Durchführung der Prozessanalyse. Die Prozessanalyse wird in zwei Schritten durchgeführt:

1. Istaufnahme der bestehenden Organisation

Hierfür werden Organisations- und Arbeitsunterlagen ausgewertet und gegebenenfalls

Mitarbeiterinterviews durchgeführt.

85

Page 86: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse - Prozessanalyse

2. Istanalyse der Prozesse

Folgende Methoden werden zum Beispiel eingesetzt:

Benchmarking

Schwachstellenanalyse

Workflowanalyse

Checklistentechnik

Referenzanalyse

Vorgangskettenanalyse

86

Page 87: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Systemanalyse

Die Systemanalyse ist eine praktisch anwendbare Methode der Systemtheorie.

Dabei konstruiert der Betrachter des Systems ein Modell eines bereits existierenden oder geplanten Systems zunächst als Black Box und verfeinert dieses im weiteren Verlauf.

87

Page 88: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Systemanalyse

Dabei hat der Bearbeiter eine Auswahl bezüglich der relevanten Elemente und Beziehungen des Systems zu treffen.

Das erstellte Modell ist immer ein begrenztes, reduziertes, abstrahiertes Abbild der Wirklichkeit, mit dessen Hilfe Aussagen über vergangene und zukünftige Entwicklungen und Verhaltensweisen des Systems in bestimmten Szenarien gemacht werden sollen.

88

Page 89: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Systemanalyse

Der Vorgang ist auf nahezu jedes System anwendbar, einschließlich

Physik,

Biologie,

Demographie,

Wirtschaft,

Geographie,

Technik und Informatik.

89

Page 90: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Systemanalyse

Was ist Systemanalyse?

Der ganzheitliche Ansatz Systemanalyse ist ein iterativer, heuristischer und rückgekoppelter Prozess der durch die Dimensionen:

Organisation,

Technologie und Motivation

gekennzeichnet werden kann.

90

Page 91: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Systemanalyse

Arbeitsschritte einer Systemanalyse

Festlegen der Systemgrenzen zur Unterscheidung von System und Umwelt.

Feststellen derjenigen Systemelemente, die für die Fragestellung als relevant betrachtet werden.

91

Page 92: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Systemanalyse

Feststellen derjenigen Beziehungen zwischen den Systemelementen, die für die Fragestellung als relevant betrachtet werden.

Feststellen der Systemeigenschaften auf der Makroebene.

Feststellen der Beziehungen des Systems zur Umwelt bzw. zu anderen Systemen, wenn von der Betrachtung des Systems als isoliertes oder geschlossenes System zum offenen System übergegangen wird.

92

Page 93: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Systemanalyse

Darstellung

Darstellung der Analyseergebnisse:

qualitativ: Concept-Map, Flussdiagramm, Wirkungsdiagramme

halbquantitativ: Pfeildiagramm (je-desto-Beziehungen)

quantitativ: x-y-, x-t-Diagramme u. a., mathematische Gleichungssysteme

93

Page 94: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Systemanalyse

Für die Systemanalyse werden formale Methoden und graphische Methoden eingesetzt.

Edwards behilft sich in seinem Werk mit den folgenden Elementen, um damit diverse Muster-Systeme darzustellen:

94

Page 95: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Systemanalyse

DFD (Data Flow Diagramm)

Datenflussdiagramm, stellt die Verarbeitung und Speicherung der Datenströme dar.

STD (State Transition Diagram)

Zustandsübergangsdiagramm, zeigt zeitliches Verhalten.

95

Page 96: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Systemanalyse

ERD (Entity Relationship Diagram)

Gegenstands-Beziehungs-Diagramm, stellt Datenverknüpfungen zueinander dar.

ESTD (Entity State Diagram)

Gegenstands-Zustands-Diagramm, als Mischform aus STD und ERD. Zeigt Statusänderungen in Abhängigkeit von zeitlichen Ereignissen.

96

Page 97: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Systemanalyse

Weiterhin benennt er noch die folgenden theoretisch möglichen Kombinationen, die aber praktisch nur sehr begrenzt zweckdienlich sind:

Zuordnung zwischen Datenstromdarstellung und Datenspeichern (zur Verifikation).

Zeitliche Veränderung der Datenverarbeitung durch Steuersignale (zur Funktionskontrolle).

97

Page 98: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Systemanalyse

Die Herleitung von Zuständen („States“) durch Ereignisse („Events“) und umgekehrt ist möglich.

Eine ständige Begrenzung auf eine für die jeweilige Detailierungsebene sinnvolle Elementmenge ist nötig um zu einem tauglichen, sprich durchschaubaren und damit brauchbaren Ergebnis zu kommen.

Die Darstellung unterscheidet zwischen Steuerströmen, Datenströmen, Augenblicksereignissen und physikalischen Strömen von Materie oder Energie.

98

Page 99: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Strukturierte Analyse (SA)

Die Strukturierte Analyse (SA) ist eine hauptsächlich von Tom DeMarco entwickelte Methode zur Erstellung einer formalen Systembeschreibung im Rahmen der Softwareentwicklung.

Sie wird während der Analysephase eines Software-Projekts eingesetzt.

Strukturiertes Design verfeinert die Ergebnisse der SA soweit, dass sie dann umgesetzt werden können. Sie ist eine Methode der Systemanalyse.

99

Page 100: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Strukturierte Analyse (SA)

Das Ergebnis der Strukturierten Analyse ist ein hierarchisch gegliedertes technisches Anforderungsdokument für das Systemverhalten.

100

Page 101: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Strukturierte Analyse (SA)

Die Strukturierte Analyse ist eine graphische Analysemethode, die mit Hilfe eines Top-Down-Vorgehens ein komplexes System in immer einfachere Funktionen bzw. Prozesse aufteilt und gleichzeitig eine Datenflussmodellierung durchführt.

In ihrer Grundform ist die SA eine statische Analyse, die jedoch später um Methoden für dynamische Analysen erweitert wurde.

101

Page 102: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Strukturierte Analyse (SA)

Strukturierte Analyse

In der Strukturierten Analyse werden folgenden Elemente verwendet:

Kontextdiagramm (engl. Context-Diagram):

Dieses Diagramm ist die Wurzel des Analyse-Baums. Es grenzt das System von seiner Umwelt ab und definiert damit, welche Aspekte von der Analyse betrachtet werden und welche nicht.

102

Page 103: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Strukturierte Analyse (SA)

Datenflussdiagramm (engl. Data Flow Diagram, kurz DFD): Ein DFD visualisiert in welche Teilprozesse sich der auf dem DFD dargestellte Prozess aufteilt und wie die Verwendung der Daten in diesem Prozess abläuft.

103

Page 104: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Strukturierte Analyse (SA)

Minispezifikation (engl. Mini-Specification): Die Mini-Spec ist eine formale Beschreibung eines im Rahmen der Analyse nicht mehr weiter geteilten Elementarprozesses.

Die Beschreibung erfolgt mit Hilfe eines Pseudocodes, der nicht genormt ist und sich im Regelfall an der später verwendeten Programmiersprache orientiert. Weitere Möglichkeiten der Beschreibung sind Entscheidungstabellen und -bäume.

104

Page 105: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Strukturierte Analyse (SA)

Datenwörterbuch (engl. Data Dictionary, kurz DD):

Eine Sammlung aller Datendefinitionen, die in der Analyse verwendet werden.

105

Page 106: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Strukturierte Analyse (SA)

Die ersten beiden Diagramme verwenden folgende grafischen Elemente:

Datenfluss, dargestellt als ein Pfeil

Daten, Beschriftung am Pfeil

106

Page 107: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Strukturierte Analyse (SA)

Speicher, zwei parallele waagerechte Linien, dazwischen der Name des Speichers

Teil- und Elementarprozesse, Kreis mit dem Namen und der Nummer des Teilprozesses in dem Kreis

Externe Datenempfänger/sender (nur auf dem Kontextdiagramm), Viereck mit eingeschlossenem Namen

107

Page 108: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Strukturierte Analyse (SA)

Strukturierte Real-Time-Analyse (RT)

Die Strukturierte Real-Time-Analyse erweitert die normale strukturierte Analyse um eine Echtzeitkomponente.

108

Page 109: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Strukturierte Analyse (SA)

Erreicht wird dies durch die Festlegung des Verhaltens der Prozessschicht unter allen möglichen externen und internen Bedingungen und Betriebsarten.

Entworfen wurde das System von Imtiaz A. Pirbhai und Derek J. Hatley.

109

Page 110: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Strukturierte Analyse (SA)

Dynamische Analyse

Neben den Definitionen der Statischen Analyse werden zusätzlich folgende Elemente definiert:

Entscheidungstabelle (engl. Decision Table, kurz DT): Aus mehreren Eingangswerten wird in tabellarischer Form definiert wie der Ausgangswert gesetzt wird.

110

Page 111: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Strukturierte Analyse (SA)

Zustandsübergangsdiagramm (engl. State Transition Diagram, kurz STD):

Zustände werden auf diesem Diagramm als Vierecke und Übergänge als Pfeile dargestellt.

Das STD hat Eingangs- und Ausgangswerte, die in Abhängigkeit von den Übergängen und Zuständen gesetzt werden.

111

Page 112: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Strukturierte Analyse (SA)

Prozessaktivierungstabelle (engl. Process Activation Table, kurz PAT):

Die Tabelle beschreibt die Reihenfolge der Aktivierung der in der Tabelle aufgezählten Prozesse.

Ein DFD beinhaltet stets nur eine PAT und beliebig viele DT und STD. Alle drei neuen Elemente werden grafisch durch einen senkrechten Strich dargestellt. Pfeile von links sind die Eingangs-, Pfeile nach rechts die Ausgangsparameter.

112

Page 113: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Strukturierte Analyse (SA)

Kontrollflüsse (engl. Control Flow):

Dargestellt als gestrichelter Pfeil werden über Kontrollflüsse nur Daten mit Boolescher Definition gesendet.

Diese dienen der Ansteuerung der DT und STD und tragen selbst keine wahren Daten, sondern dienen nur der Modellierung des dynamischen Ablaufs.

113

Page 114: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Strukturierte Analyse (SA)

Verwendung in der Praxis

Eins der größten Softwareprojekte, die mit Hilfe der Strukturierten Analyse in Deutschland realisiert wurden, ist die Software für den Zentralrechner des Kampfflugzeugs Tornado.

114

Page 115: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – Strukturierte Analyse (SA)

Ansonsten ist die Strukturierte Analyse vielerorts durch die Unified Modeling Language abgelöst, wird aber noch in vielen Projekten eingesetzt.

Softwaretools

Innovator von MID

case/4/0 von microTOOL

115

Page 116: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – OO Analyse und Design

Objektorientierte Analyse und Design (OOAD) ist eine Phase der objektorientierten Erstellung eines Softwaresystems, welche sich in den Teil der Domänenmodellierung (Objektorientierte Analyse) und den Teil des Systementwurfs (Objektorientiertes Design) aufgliedert.

116

Page 117: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – OO Analyse und Design

In der Analyse geht es darum, die Anforderungen zu erfassen und zu beschreiben, die das zu entwickelnde Softwaresystem erfüllen soll.

Stark vereinfacht ausgedrückt sucht und sammelt man in dieser Phase alle Fakten, stellt diese dar und überprüft sie.

Dies geschieht oft in Form eines textuellen Pflichtenheftes oder der Software Requirements Specification.

117

Page 118: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – OO Analyse und Design

Das darauf aufbauende Objektorientierte Analysemodell (OOA-Modell) ist eine fachliche Beschreibung mit objektorientierten Konzepten, oft mit Elementen der Unified Modeling Language (UML) notiert.

Es hebt das Wesentliche hervor und lässt Unwichtiges weg. Ein Bezug zur Informationstechnik ist in dieser Phase ausdrücklich unerwünscht.

118

Page 119: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – OO Analyse und Design

Das OOA-Modell kann ein statisches und/oder ein dynamisches Teilmodell enthalten. Es kann auch einen Prototypen der Benutzerschnittstelle enthalten.

119

Page 120: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – OO Analyse und Design

Beim objektorientierten Design wird das in der Analyse erstellte Domänenmodell weiterentwickelt und darauf aufbauend ein Systementwurf erstellt.

Das Design berücksichtigt neben den fachlichen Aspekten des Auftraggebers aus der Analyse auch technische Gegebenheiten.

In einem Wasserfall-Vorgehensmodell folgt als nächste Phase die objektorientierte Programmierung (OOP).

120

Page 121: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – OO Analyse und Design

Vorgehensmodelle

Mehrere Autoren und Hersteller kommerzieller Werkzeuge haben versucht, den Entwicklern durch die Beschreibung von Vorgehensmodellen eine Sammlung von Werkzeugen an die Hand zu geben, die dazu dienen soll, die Zusammenarbeit der an der Entwicklung Beteiligten zu verbessern, die Kommunikation mit dem Kunden zu verbessern, das Verständnis für den eigenen Entwurf zu vertiefen und die Dokumentation zu standardisieren.

121

Page 122: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – OO Analyse und Design

UML

Der Erfolg stellte sich ein, als in der Firma Rational Software Corporation die drei dominanten Autoren James Rumbaugh, Grady Booch und Ivar Jacobson zusammen eine erste Version der vereinigten Modellierungssprache Unified Modeling Language (UML) erarbeiteten.

122

Page 123: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

2. Analyse – OO Analyse und Design

Sie haben sich auf eine gemeinsame Notation zur Darstellung von Modellierungsergebnissen geeinigt.

UML ist mittlerweile durch die Object Management Group (OMG) standardisiert und hat sich in der Praxis bewährt und durchgesetzt. Allerdings ist auch UML eher ein Werkzeugkasten als ein klares Vorgehensmodell.

123

Page 124: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf

Softwarearchitektur

Strukturiertes Design (SD)

Objektorientiertes Design (OOD)

Unified Modeling Language (UML)

Fundamental Modeling Concepts (FMC) 124

Page 125: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – Softwaerarchitektur

Eine Softwarearchitektur beschreibt die grundlegenden Komponenten und deren Zusammenspiel innerhalb eines Softwaresystems.

Eine Definition von Helmut Balzert beschreibt den Begriff als „eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie Beschreibung ihrer Beziehungen“ (Lit.: Balzert, S. 716).

125

Page 126: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – Softwaerarchitektur

Die beschriebenen Komponenten bilden eine Zerlegung des Gesamtsystems, d. h., jedes Softwareelement ist einer Architekturkomponente eindeutig zugeordnet.

Die Softwarearchitektur ist zu unterscheiden vom Softwareentwurf.

126

Page 127: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – Softwaerarchitektur

Während sich Entwurfsentscheidungen auf lokale Aspekte innerhalb des architektonischen Rahmens der Software beziehen, ist die Softwarearchitektur eine globale Eigenschaft des Gesamtsystems.

127

Page 128: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – Softwaerarchitektur

Im Rahmen der Softwareentwicklung repräsentiert die Softwarearchitektur die früheste Softwaredesign-Entscheidung (Architekturentwurf).

Sie wird wesentlich durch nicht-funktionale Eigenschaften wie Modifizierbarkeit, Wartbarkeit, Sicherheit oder Performance bestimmt.

128

Page 129: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – Softwaerarchitektur

Eine einmal eingerichtete Softwarearchitektur ist später nur mit hohem Aufwand abänderbar.

Die Entscheidung über ihr Design ist somit eine der kritischsten und wichtigsten Punkte im Entwicklungsprozess einer Software.

Zur grafischen Visualisierung von Softwarearchitekturen werden unterschiedliche Methoden eingesetzt.

129

Page 130: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – Softwaerarchitektur

Beispielsweise:

Unified Modeling Language (UML)

Fundamental Modeling Concepts (FMC)

130

Page 131: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – Softwaerarchitektur

Mit der Bewertung von Softwarearchitekturen befasst sich die Softwarearchitekturbewertung.

Beispiel

Eine Architekturbeschreibung umfasst etwa im Falle einer Web-Anwendung den Aufbau des Systems aus Datenbanken, Web-/ Application-Servern, E-Mail- und Cachesystemen − siehe etwa Wikipedia selbst − wobei häufig auch Diagramme (z. B. in der Unified Modeling Language) zum Einsatz kommen.

131

Page 132: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – Strukturiertes Design

Strukturiertes Design (SD) ist ein Entwurfsmuster in der Softwaretechnik nach Edward Yourdon und Larry Constantine, welches modulares Design unterstützt, um neben der reinen Funktionshierarchie auch die Wechselwirkungen von übergeordneten Modulen zu beschreiben. SD wird mit der Strukturierten Analyse (SA) in der Softwaretechnik verwendet.

132

Page 133: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – Strukturiertes Design

Das Strukturierte Design schlägt eine Brücke zwischen der technologieneutralen Analyse und der eigentlichen Implementierung.

Im Strukturierten Design werden technische Randbedingungen eingebracht und die Grobstruktur des Systems aus technischer Sicht festgelegt.

Es stellt damit die inhaltliche Planung der Implementierung dar.

133

Page 134: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – Strukturiertes Design

Die Methodik stellt mittels Strukturdiagrammen funktionale Module hierarchisch dar und zeigt dadurch die einzelnen Aufrufhierarchien der Module untereinander.

Ein funktionales Modul besteht aus einer oder mehreren funktionalen Abstraktionen.

134

Page 135: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – Strukturiertes Design

Diese wiederum stellt eine der ersten Abstraktionsmechanismen dar und gruppiert mehrere zusammengehörende Programmbefehle zu Einheiten (Funktionen).

Ein Beispiel wäre die Berechnung der Quadratwurzel sqrt(x).

135

Page 136: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – Strukturiertes Design

Der Benutzer muss keine Details über die Implementierung wissen, sondern wendet die Funktion nur an.

Dafür benötigt er eine entsprechende Schnittstellenbeschreibung, die ebenso zum Strukturierten Entwurf gehört wie das Erstellen der Modulhierarchie.

136

Page 137: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – Strukturiertes Design

Ein Funktionales Modul besitzt kein internes Gedächtnis, das heißt es beinhaltet keine Daten (private Daten), die nur im Modul sichtbar sind.

Es kann nur in globalen Daten Informationen hinterlegen (beispielsweise bei der Berechnung einer Zufallszahl).

Spätere darauf aufbauende Methoden, wie das Modulare Design (MD), führen abstrakte Datentypen und Datenobjekte ein.

137

Page 138: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – Strukturiertes Design

Bei Banken, Versicherungen und im Embedded-Bereich finden noch viele Systementwicklungen mit strukturierten Methoden statt.

Insbesondere im Bereich des m-Business (Mobile-Business) werden oft Rechnersysteme verwendet, die über limitierte Ressourcen verfügen, für die eine objektorientierte Realisierung mit ihrem Overhead zu teuer ist.

138

Page 139: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – Strukturiertes Design

Weiterhin sind im Rahmen der Integration von bestehenden Anwendungen im Rahmen von EAI oft Teilsysteme zu realisieren, die nicht mit objektorientierten Sprachen umgesetzt werden können.

Daher würden objektorientierte Analyse und Design falsche Implementierungsvorbereitungen darstellen.

139

Page 140: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – Strukturiertes Design

Funktionsorientierte Methode

Aufgaben werden top-down in Teilaufgaben zerlegt und dann diese auf die Module abgebildet (Prinzip der Modularisierung).

Beschreibungsmittel sind Strukturdiagramme in denen die Module und die Verbindungen zwischen Modulen dargestellt werden.

140

Page 141: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – Strukturiertes Design

Beispiel

Menü Kundenverwaltung wird unterteilt in Formular Kunde und Bericht Kunde.

Formular Kunde wird erneut unterteilt in Aktualisieren und Umsatzrabatt, Bericht Kunde in Seitenansicht und Drucken.

141

Page 142: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – OO Design

Objektorientierte Analyse und Design (OOAD) ist eine Phase der objektorientierten Erstellung eines Softwaresystems, welche sich in den Teil der Domänenmodellierung (Objektorientierte Analyse) und den Teil des Systementwurfs (Objektorientiertes Design) aufgliedert.

142

Page 143: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – OO Design

In der Analyse geht es darum, die Anforderungen zu erfassen und zu beschreiben, die das zu entwickelnde Softwaresystem erfüllen soll.

Stark vereinfacht ausgedrückt sucht und sammelt man in dieser Phase alle Fakten, stellt diese dar und überprüft sie.

Dies geschieht oft in Form eines textuellen Pflichtenheftes oder der Software Requirements Specification.

143

Page 144: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – OO Design

Das darauf aufbauende Objektorientierte Analysemodell (OOA-Modell) ist eine fachliche Beschreibung mit objektorientierten Konzepten, oft mit Elementen der Unified Modeling Language (UML) notiert.

Es hebt das Wesentliche hervor und lässt Unwichtiges weg.

144

Page 145: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – OO Design

Ein Bezug zur Informationstechnik ist in dieser Phase ausdrücklich unerwünscht. Das OOA-Modell kann ein statisches und/oder ein dynamisches Teilmodell enthalten. Es kann auch einen Prototypen der Benutzerschnittstelle enthalten.

145

Page 146: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – OO Design

Beim objektorientierten Design wird das in der Analyse erstellte Domänenmodell weiterentwickelt und darauf aufbauend ein Systementwurf erstellt.

Das Design berücksichtigt neben den fachlichen Aspekten des Auftraggebers aus der Analyse auch technische Gegebenheiten.

In einem Wasserfall-Vorgehensmodell folgt als nächste Phase die objektorientierte Programmierung (OOP).

146

Page 147: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf - UML

Die Unified Modeling Language (UML, engl. Vereinheitlichte Modellierungs-Sprache) ist eine von der Object Management Group (OMG) entwickelte und standardisierte Sprache für die Modellierung von Software und anderen Systemen.

Im Sinne einer Sprache definiert die UML dabei Bezeichner für die meisten Begriffe, die für die Modellierung wichtig sind, und legt mögliche Beziehungen zwischen diesen Begriffen fest.

147

Page 148: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf - UML

Die UML definiert weiter grafische Notationen für diese Begriffe und für Modelle von statischen Strukturen und von dynamischen Abläufen, die man mit diesen Begriffen formulieren kann.

Die UML ist heute eine der dominierenden Sprachen für die Modellierung von betrieblichen Anwendungssystemen (Softwaresystemen).

Der erste Kontakt zur UML besteht häufig darin, dass Diagramme der UML im Rahmen von Softwareprojekten zu erstellen, zu verstehen oder zu beurteilen sind:

148

Page 149: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf - UML Projektauftraggeber und Fachvertreter prüfen und

bestätigen zum Beispiel Anforderungen an ein System, die Wirtschaftsanalytiker in Anwendungsfalldiagrammen der UML festgehalten haben.

Softwareentwickler realisieren Arbeitsabläufe, die Wirtschaftsanalytiker in Zusammenarbeit mit Fachvertretern in Aktivitätsdiagrammen beschrieben haben.

Systemingenieure installieren und betreiben Softwaresysteme basierend auf einem Installationsplan, der als Verteilungsdiagramm vorliegt.

149

Page 150: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf - UML

Die graphische Notation ist jedoch nur ein Aspekt, der durch die UML geregelt wird.

Die UML legt in erster Linie fest, mit welchen Begriffen und welchen Beziehungen zwischen diesen Begriffen sogenannte Modelle spezifiziert werden – Diagramme der UML zeigen nur eine graphische Sicht auf Ausschnitte dieser Modelle.

150

Page 151: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf - UML

Die UML schlägt weiter ein Format vor, in dem Modelle und Diagramme zwischen Werkzeugen ausgetauscht werden können.

Ein Vorgehensmodell, welches die UML anwendet, kann wegen der strengen Formalisierung kein agiler Prozess sein.

151

Page 152: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – Fundamental Modeling Concepts

Fundamental Modeling Concepts (FMC) ist eine semi-formale Methodik zur Kommunikation über komplexe Softwaresysteme.

152

Page 153: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – Fundamental Modeling Concepts

Seit Ende der 1970er Jahre wurden ihre Grundlagen von Siegfried Wendt und seinen Mitarbeitern und Schülern an der Universität Kaiserslautern entwickelt.

153

Page 154: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

3. Entwurf – Fundamental Modeling Concepts

Am 1999 unter Leitung von Siegfried Wendt gegründeten Hasso-Plattner-Institut an der Universität Potsdam wurden diese Konzepte zunächst unter dem Namen SPIKES (Structured Plans for Improving Knowledge Transfer in Engineering of Systems) gelehrt, bevor sie im Jahre 2001 den Namen FMC (Fundamental Modeling Concepts) erhielten.

154

Page 155: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

4. Programmierung

Normierte Programmierung

Strukturierte Programmierung

Objektorientierte Programmierung (OOP)

Funktionale Programmierung

155

Page 156: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

5. Validierung und Verifikation

Modultests (Low-Level-Test)

Integrationstests (Low-Level-Test)

Systemtests (High-Level-Test)

Akzeptanztests (High-Level-Test)

156

Page 157: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

6. Anforderungsmanagement

157

Page 158: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

7. Projektmanagement

Risikomanagement Projektplanung

Projektverfolgung und -steuerung

Management von Lieferantenvereinbarungen

158

Page 159: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

8. Qualitätsmanagement

Capability Maturity Model Spice (Norm) (Software Process Improvement

and Capability Determination) Incident Management Problem Management Softwaremetrik (Messung von

Softwareeigenschaften) statische Analyse (Berechnung von

Schwachstellen) Softwareergonomie

159

Page 160: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

9. Konfigurationsmanagement

Versionsverwaltung

Änderungsmanagement / Veränderungsmanagement

Release Management

Application Management (ITIL)

160

Page 161: Ralf-Oliver Mevius Inf. (21) - Programming Exercises Bachelor Informatik (21) Programming Exercises Teil 2

Ral

f-O

live

r M

evi

us

Inf. (21) - Programming Exercises

10. Dokumentation

Software-Dokumentationswerkzeug

Systemdokumentation (Weiterentwicklung und Fehlerbehebung)

Betriebsdokumentation (Betreiber/Service) Bedienungsanleitung (Anwender)

Geschäftsprozesse (Konzeptionierung der Weiterentwicklung)

Verfahrensdokumentation (Beschreibung rechtlich relevanter Softwareprozesse)

161