Software Engineering I

Transkript

1 Vorlesung Analysephase Modellierung mit SA/SD Analysephase 1

2 Entwicklungsphasen: Inputs, Outputs Kundenanforderungen, Lastenheft (CRS SAS, MODs, Implementierung, Modultests Pflichtenheft (SRS) Systemspezifikation (Grob-,Feinentwurf) Systemtestplan (STP), Systemvalidierungsplan (SVP) Analyse Design Codierung Test Einführung Wartung Architekturspezifikation (SAS), Modulspezifikationen (MODs) Systemtestreport (STR), Systemvalidierungsreport (SVR) Systemmodellierung, Pflichtenheft (SRS) MODs, Systemintegrationsreport (SIR) Bugreports, Change Requests (CRQ) 2

3 Analysephase Beschreibung des zu lösenden Problems und aller wichtigen Umgebungsbedingungen - möglichst vollständig und eindeutig. Ergebnis der Anforderungsermittlung ist das Lastenheft (CRS), welches die Kundenanforderungen enthält (Klärung des WAS) Untersuchung der Durchführbarkeit der geplanten Systementwicklung Ergebnis der Anforderungsanalyse ist das Pflichtenheft (SRS), welches die aus den Kundenanforderungen abgeleitete Systemanforderungen und ein Systemmodell enthält (Klärung des WIE). 3

4 Die Analysephase Ziel der Analysephase ist die vollständige konsistente eindeutige Definition des zu realisierenden Produkts durch die Spezifizierung eines Produktmodells. Das Produktmodell kann bestehen aus: Pflichtenheft (SRS) Vertragsgrundlage! Analysemodell Prototypen Analysephase 4

5 Das Pflichtenheft (SRS) Aufgabe: Zusammenfassung aller fachlichen Anforderungen an das zu entwickelnde System Adressaten: Auftraggeber, Auftragnehmer (Projektleiter, Systemanalytiker, Entwickler,...) Inhalt: fachlicher Funktions-, Daten- und Leistungsumfang, Qualitätsanforderungen Abnahmekriterien (spätestens hier festzulegen)! Analysephase 5

6 Pflichtenheft: Standards Ein sehr bekannter Standard zum Requirements Management ist der IEEE 830 (Recommended Practice for Software Requirements Specifications). Er ist ein konkreter praxisnaher Standard für die Beschreibung und die Definition von Softwareanforderungen. Es werden Strukturen vorgeben für den Aufbau der Dokumentation, den Aufbau der einzelnen Anforderungen und sogar zur Formulierung der Anforderungen. Eine gute Ergänzung hierzu ist der Standard IEEE 1362 (Guide for Information Technology System Definition, Definition - Concept of Operations Document), der letztendlich ein Standard für Anforderungsdokumente (Lasten-/Pflichtenhefte) darstellt. Eine weitere sinnvolle Ergänzung zu den beiden genannten Standards sind die Spezifikationen aus VDI 2519 Blatt 1 (Vorgehensweise bei der Erstellung von Lasten-/Pflichtenheften). Hier wird definiert was Lasten- und Pflichtenhefte sind, was sie enthalten sollten und wie sie erstellt werden sollten. Analysephase 6

7 Methodik zur Erstellung des Produktmodells (Iterative) Erstellung des Pflichtenheftes (SRS) Begleitend auf Basis des Pflichtenhefts: Iterative Erstellung eines Produktmodells unter Einsatz der gewählten Methoden (z.b. SA/SD, OOAD) Iterative Konzeption der Benutzungsoberfläche, ggf. Erstellung eines entsprechenden Prototyps Erstellung einer ersten Version des Benutzerhandbuches Analysephase 7

8 Modellierungskonzepte Modellierungskonzepte werden verwendet zur Anforderungsspezifikation Systembeschreibung aus verschiedenen Sichten (Statik, Dynamik, Logik) Auftraggeber und Auftragnehmer müssen diese Modellierungskonzepte (Notationen) verstehen. Früher: Strukturierte Methoden (z.b. SA/SD Heute: Objektorientierte Methoden (z.b. OOAD) Analysephase 8

9 Basiskonzepte zur Modellierung textuell grafisch Text Nummerierte Anforderungen Struktogramm Funktionsbaum Kollaborationsdiagramm Sequenzdiagramm Entscheidungstabellen Pseudocode Regeln informal semiformal formal DFDs Klassendiagramm Data Dictionary ERD Zustandsautomat Petri- Netze Entscheidungsbäume Petri-Netz (textuell) 9

10 Modellierung mit SA/SD Strukturierte Analyse / Strukturiertes Design Analysephase 10

11 Strukturierte Analyse (SA) DeMarco, 1975, Structured Analysis and System Specification Varianten der Strukturierten Analyse: Weinberg, 1978: Structured Analysis Gane & Sarson, 1979: Structured Systems Analysis McMenamin & Palmer, 1984: Modern Structured Analysis Yourdon, 1989: Modern Structured Analysis Hier werden die Erfahrungen der Strukturierten Analyse seit dem Erscheinen von DeMarco s Methode gebündelt. Es wird keine neue Methode propagiert, jedoch wird die Strukturierte Analyse im gesamten Umfeld des Software-Engineering betrachtet. ( SA/RT Ergänzt um Modellierung für Dynamik Analysephase 11

12 SA: Basiskonzepte Die Strukturierte Analyse fußt im Wesentlichen auf folgenden, miteinander verknüpften Basiskonzepten: 1. Datenflussdiagramm (Data Flow Diagram (DFD)) Strukturierung des Systems Funktionen und Daten und ihr Zusammenwirken 2. Datenlexikon (Data Dictionary (DD)) Strukturierung der Daten Detaillierte Datenbeschreibung 3. Primitive Prozessspezifikation (MiniSpec) Detaillierte Funktionsbeschreibung 4. Funktionsbaum Strukturierung der Funktionen 12

13 SA: Hierarchiekonzept 13

14 DFD: Definitionen Datenflüsse sind vergleichbar mit Pipelines, durch die Daten transportiert werden. Datenspeicher bilden eine Ablagemöglichkeit für Daten, bei denen sich der Erstellungszeitpunkt vom Gebrauchszeitpunkt unterscheidet. Prozesse haben die Aufgabe, Eingabedaten in Ausgabedaten zu verarbeiten und enthalten die hierfür notwendigen Algorithmen. Terminatoren (Schnittstellen) stehen für die Beziehungen des Systemes zur Außenwelt. Sie senden oder empfangen Daten, verarbeiten diese jedoch nicht. 14

15 DFD: Datenflüsse 15

16 DFD: Semantische Regeln DFD beschreibt den Datenfluss, nicht den Kontrollfluss Schnittstellen sind so zu wählen, dass die ursprüngliche Datenquelle und Senke angegeben werden (Also die Benutzerrolle, nicht bspw. Tastatur und Drucker) Datenflussname = <Substantiv>!Typ Funktionsname = <Verb><Objekt>!Aktion 16

17 DFD: Fehlermöglichkeiten Folgendes funktioniert nicht, bzw ist nicht sinnvoll: 17

18 Strukturierte Analyse Unter Anwendung von Datenflussdiagrammen (DFD) wird eine hierarchische Betrachtung des Systems modelliert. Kontextdiagramm (nullte Ebene): Beschreibt die Umwelt des Systemes, es gibt genau einen Prozess. Diagramm 0 (erste Ebene): Der Gesamtsystems-Prozess, Prozess 0, wird in Subsysteme zerlegt; Angabe der Daten, welche zwischen den Subsystemen bzw. Teilfunktionen fließen. Subdiagramme (n-te Ebene): Prozessverfeinerung, Zerlegung des vorherigen Subsystemes in weitere Subsysteme. MiniSpec: Wurde ein Prozess ausreichend verfeinert, wird er abschließend durch eine MiniSpec beschrieben. Prozesse, Datenspeicher und Datenflüsse sollen mit einem möglichst prägnanten Namen versehen werden. Zum Beispiel: prüfe Passwort, aber nicht: verarbeite Datei (Welche Datei? - Wie wird sie verarbeitet?). 18

19 SA: Kontextdiagramm Syntax enthält nur einen Prozess, dieser erhält die Nummer 0 und stellt das Gesamtsystem dar verfügt über mindestens eine Schnittstelle Semantik beschreibt den Anwendungsbereich des modellierten Systemes zeigt Datenflüsse, welche Systemgrenzen überschreiten ist die Zusammenfassung von Diagramm 0 19

20 SA: Diagramm 0 Das Diagramm 0 beschreibt die Verfeinerung des Kontextdiagrammes: Der Prozess 0 aus dem Kontextdiagramm wird in Teilprozesse zerlegt. Speicher werden eingefügt. 20

21 SA: Prozessverfeinerung Jeder Prozess kann wieder zu einem neuen Diagramm verfeinert werden, welches folgende Bedingungen erfüllen muss: Der Prozess wird in Teilprozesse zerlegt. Jeder Prozess wird fortlaufend nummeriert. Wurde ein Prozess ausreichend verfeinert, wird er abschließend durch eine MiniSpec beschrieben. Die Anzahl der Prozesse pro Diagramm sollte sieben nicht überschreiten. DFD 1, DFD 2, DFD n... DFD 1.1, DFD DFD n.m... 21

22 SA: Mini Specs Bei den MiniSpecs handelt es sich um Subsysteme, welche nicht mehr (sinnvoll) durch Datenflussdiagramme aufgeteilt werden können. Sie beschreiben implementierungsunabhängig, wie Eingangsdaten in Ausgangsdaten umgewandelt werden. Erscheint eine Verfeinerung für eine Funktion nicht mehr als sinnvoll, so wird zu dieser Funktion eine Mini Spec angegeben. Diese sollte mit einer der folgenden Methoden erstellt werden: Pseudo Code Struktogramm / Programmablaufplan Entscheidungstabelle / -baum 22

23 Data Dictionary (DD) Das Datenlexikon ist ein Verzeichnis, das Informationen über die Struktur von Daten, ihre Eigenschaften und ihre Verwendung enthält. Engl.: Data Dictionary (DD) Zur Beschreibung der Speicherinhalte Symbol Bedeutung Bsp = ist äquivalent zu A=B + Sequenz A=B+C [ ] Auswahl (xor) A=[B C] { } Wiederholung A={B} N{ }M Wiederholung N-M mal A=1{B}5 ( ) Option A=B+(C) * * Kommentar *muss* 23

24 DD: Beispiel Artikeldaten = Artikel_id + Erstellungsdatum + Titel + Text Benachrichtigungsschreiben = [Account angelegt Account gelöscht Nachricht von anderem Nutzer] Artikelanfrage = User_id + 1{ Artikel_id }20 Kunde = Kunden_id + Name + Adresse Buch = Buch_id + Autor + Titel + Preis Buchliste = {Buch} Einkauf = {Bestellung + Gesamtbetrag} Kundenliste = {Kunde} Kundenstatus = [ reich arm ] Zimmerart = [ Einzelzimmer Doppelzimmer ] * Ein Kommentar ist immer wichtig. * 24

25 SA: Integritätsregeln In der Strukturierten Analyse sind folgende Integritätsregeln zu beachten: Jeder Datenfluß hat einen Namen. Ausnahme: Zugriff auf einen kompletten Speicherinhalt Jeder Datenflußname ist im DD beschrieben Jeder Speicher hat einen Namen Jeder Speichername ist im DD beschrieben Alle Datenflüsse in einem untergeordneten DFD müssen im übergeordneten DFD vorkommen oder eine Komponente eines Datenflusses aus dem übergeordneten DD sein. Die Komponenteneigenschaft ergibt sich aus dem DD 25

26 Strukturierte Analyse - Design Pattern Methodik zur Systemmodellierung mit der SA: 1. Schnittstellen und Ein/Ausgaben finden 2. Funktionen finden 3. Speicher finden 4. Datenflüsse finden 5. Data Dictionary erstellen 6. Konsolidieren des Modells 7. Iterative Verfeinerung 8. Mini-Spezifikationen erstellen 26

27 SA: Vor-/Nachteile Stärken der Strukturierten Analyse: leicht verständlich Kombination bewährter Basiskonzepte ermöglicht Top-Down-Erarbeitung des Systems hierarchische Gliederung sorgt für Übersichtlichkeit Kontextdiagramm ähnlich wie Use Case Zusammenhang zu ER-Modellen herstellbar (über Speicher) Schwächen der Strukturierten Analyse: Schnittstellen und Speicher können nicht verfeinert werden Logik, Dynamik und Kontrollfluss können nicht modelliert werden nur der Datenfluss wird analysiert keine Lokalität von Daten, daher kaum für OO geeignet 27

28 SA/SD: Funktionsbaum DFD SD: Transformation der DFD-Prozesse in hierarchisch strukturierte Funktionen Analysephase 28

29 SD: Transformation Analyse Design A B D E F G C H K Do job B D E F A C G H K Analysephase 29

30 Systemlayout SA/SD vs. OOAD Function Function Function Function Data Function Data Function Function Data Function 30

31 Zusammenfassung SA/SD Zur Modellierung von Softwaresystemen waren Strukturierte Methoden früher weit verbreitet. Strukturierte Analyse (SA) : Erstellung eines logischen Systemmodells, bestehend aus hierarchisch strukturierten DFDs, begleitet von Data Dictionaries, MiniSpecs, etc. Grundsätzlich stellt sich in der strukturierten Analyse folgende Frage: Was soll das geplante Softwaresystem können? Strukturiertes Design (SD): beinhaltet Operationsmodell und Modulmodelle. Umsetzung der DFDs aus der SA in Strukturdiagramme. Im strukturierten Design stellt sich dann folgende Frage: Wie sollen die Funktionalitäten des Softwaresystems umgesetzt werden? Die SA/SD-Transformation ist ein kreativer, nicht formalisierbarer Prozess! Analysephase 31

32 Beispiel Strukturierte Analyse Seminarverwaltung Analysephase 32

33 Beispiel SA: Kontextdiagramm Analysephase 33

34 Beispiel SA: DFD Ebene 0 Analysephase 34

35 Beispiel SA: DFD Ebene 0 mit Speicher Analysephase 35

36 Beispiel SA: DFD Verfeinerung (Ebene 1) Analysephase 36

37 Beispiel SA: DD und DFD (Ausschnitt) Analysephase 37

38 Beispiel SA: MiniSpec Analysephase 38