Vorlesung Software Engineering I

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

1 Vorlesung Software Engineering I
Analysephase Software Engineering I VE 08: Analysephase Version

2 Entwicklungsphasen: Inputs, Outputs
Kundenanforderungen, Lastenheft (CRS SAS, MODs Implementierung, Modultests SAS, MODs Implementierung, Modultests 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), Systemvalidierungs- report (SVR) Systemmodellierung, Pflichtenheft (SRS) MODs, Systemintegrations- report (SIR) Bugreports, Change Requests (CRQ) Bugreports Change Requests (CRQ) Bugreports Change Requests (CRQ) Software Engineering I VE 08: Analysephase Version

3 Software Engineering I
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 aus Black-Box-Sicht). – Beschreibung des zu lösenden Problems und aller wichtigen Umgebungsbedingungen - möglichst vollständig und eindeutig – Untersuchung der Durchführbarkeit der geplanten Systementwicklung – Konsultation und Verhandlungen mit dem Systembenutzer – Beispiele für typische Anforderungen • gewünschte Funktionen • Beschreibung korrekter und falscher Eingabedaten und gewünschter Ausgabedaten • Anfahr- und Abschaltphase • mögliche Systemerweiterungen • logistische Anforderungen • Dokumentationsanforderungen • Leistungsparameter • Qualitätsmerkmale • Testplanung – Umgebungsbedingungen sind: • Benutzerprofil 􀃠 Art und Anzahl der Benutzer 􀃠 Ausbildung • Systemumgebung 􀃠 Hardwarekapazität 􀃠 vorhandene Systemsoftware 􀃠 vorhandene Softwarepakete – Durchführbarkeitsstudie • Technische Durchführbarkeit (Lösbarkeit der Probleme überhaupt) • Ökonomische Durchführbarkeit (Gesamtkosten, Zeitplan, Personal, Risiken, Kosten-Nutzen) Ergebnisse des Requirements Engineering: Anforderungsspezifikation Software Engineering I VE 08: Analysephase Version

4 Analysephase  Designphase
Anforderungs- Spezifikation (Lastenheft) Produkt- Spezifikation (Pflichtenheft) Anforderungs-Ermittlung Anforderungsanalyse, Systemmodellierung Design Architektur- Spezifikation “Projektstart“ Architekturentwurf Nach Balzert: - Anforderungsspezifikation - Modell = „Fachliche Lösung“ - Architektur = „Technische Lösung“ - Implementierung = „System/Produkt“  Sind strikt getrennt zu halten! Detailentwurf Modul-/Klassen- Spezifikationen Software Engineering I VE 08: Analysephase Version

5 Software Engineering I
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 (Vertragsgrundlage!) Analysemodell Prototypen Software Engineering I VE 08: Analysephase Version

6 Software Engineering I
Das Pflichtenheft Aufgabe: Zusammenfassung aller fachlichen Anforderungen Adressaten: Auftraggeber, Auftragnehmer (Projektleiter, Systemanalytiker, Entwickler, ...) Inhalt: fachlicher Funktions-, Daten- und Leistungsumfang, Qualitätsanforderungen Abnahmekriterien (spätestens hier festzulegen)! Software Engineering I VE 08: Analysephase Version

7 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. Software Engineering I VE 08: Analysephase Version

8 Methodik zur Erstellung des Produktmodells
(Iterative) Erstellung des Pflichtenheftes 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 Software Engineering I VE 08: Analysephase Version

9 Modellierungskonzepte
Modellierungskonzepten werden verwendet zur Anforderungsspezifikation Sie beschreiben das System aus verschiedenen Sichten (Statik, Dynamik, Logik) Auftraggeber und Auftragnehmer müssen diese Modellierungskonzepte (Notationen) verstehen. Heute weitverbreitet: UML-Diagramme Software Engineering I VE 08: Analysephase Version

10 Basiskonzepte zur Modellierung
Petri- Netze ERD grafisch Zustands- automat Entscheidungs- bäume DFDs Klassendiagramm Struktogramm Funktionsbaum Kollaborationsdiagramm Sequenzdiagramm Entscheidungstabellen Letzte Woche bei Herrn Stuckert Pseudocode Data Dictionary Petri-Netz (textuell) Nummerierte Anforderungen textuell Text Regeln informal semiformal formal Software Engineering I VE 08: Analysephase Version

11 Software Engineering I
Systemanalyse mit UML UML Design Pattern Software Engineering I VE 08: Analysephase Version

12 Software Engineering I
UML Design Pattern Software Engineering I VE 08: Analysephase Version

13 Software Engineering I
UML Design Pattern Verhaltensorientierte Methodik zur Systemmodellierung mit der UML: Anwendungsfälle ermitteln Ermitteln aller Aktoren und Uses Cases aus Benutzersicht Jeden Use Case mit Szenarios (Aktivitätendiagramme, Sequenzdiagramme) beschreiben Systemobjekte und -daten identifizieren In den Use-Case-Szenarios die Systemobjekte und -daten identifizieren Für die identifizierten Systemobjekte und –daten Klassendiagramme erstellen Systemarchitektur modellieren Klassendiagramme in Komponentendiagrammen sinnvoll gruppieren Schnittstellen entwerfen Komponenten im Verteilungsdiagramm sinnvoll gruppieren Systemdynamik modellieren Anhand der Use-Case-Szenarios für die Interaktion der Aktoren und Objekte Sequenzdiagramme ableiten Für die Klassendiagramme anhand der Sequenzdiagramme Zustandsdiagramme erstellen Implementierung Klassen ausprogrammieren Software Engineering I VE 08: Analysephase Version

14 Strukturierte Analyse
SA/SD Strukturierte Analyse Software Engineering I VE 08: Analysephase Version

15 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 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. Das Ergebnis der Strukturierten Analyse ist ein hierarchisch gegliedertes technisches Anforderungsdokument für das Systemverhalten. 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. Software Engineering I VE 08: Analysephase Version

16 Software Engineering I
SA: Konzepte Die Strukturierte Analyse fußt im Wesentlichen auf folgenden, miteinander verknüpften Basiskonzepten: Datenflussdiagramm (Data Flow Diagram (DFD)) Strukturierung des Systems Funktionen und Daten und ihr Zusammenwirken Datenlexikon (Data Dictionary (DD)) Strukturierung der Daten Detaillierte Datenbeschreibung Primitive Prozessspezifikation (MiniSpec) Detaillierte Funktionsbeschreibung Funktionsbaum Strukturierung der Funktionen DFD -> Aktivitätendiagramm Software Engineering I VE 08: Analysephase Version

17 Software Engineering I
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. Software Engineering I VE 08: Analysephase Version

18 Software Engineering I
DFD: Datenflüsse Software Engineering I VE 08: Analysephase Version

19 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 Software Engineering I VE 08: Analysephase Version

20 DFD: Fehlermöglichkeiten
Folgendes funktioniert nicht, bzw ist nicht sinnvoll: Software Engineering I VE 08: Analysephase Version

21 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?). Software Engineering I VE 08: Analysephase Version

22 SA: Hierarchiekonzept
Software Engineering I VE 08: Analysephase Version

23 Software Engineering I
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 Software Engineering I VE 08: Analysephase Version

24 Software Engineering I
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. Software Engineering I VE 08: Analysephase Version

25 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 ... Software Engineering I VE 08: Analysephase Version

26 Software Engineering I
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 Beispiel Unbenutzte User-Accounts löschen: Alle User-Accounts aus Datenbank selektieren; if letzter Login > 365 Tage then verschicke Benachrichtigungsmail else if letzter Login > 400 Tage then lösche Account Software Engineering I VE 08: Analysephase Version

27 Software Engineering I
Data Dictionary (DD) 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* 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 Software Engineering I VE 08: Analysephase Version

28 Software Engineering I
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. * Software Engineering I VE 08: Analysephase Version

29 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 Software Engineering I VE 08: Analysephase Version

30 Strukturierte Analyse - Design Pattern
Methodik zur Systemmodellierung mit der SA: Schnittstellen und Ein/Ausgaben finden Funktionen finden Speicher finden Datenflüsse finden Data Dictionary erstellen Konsolidieren des Modells Iterative Verfeinerung Mini-Spezifikationen erstellen Nach Balzert Software Engineering I VE 08: Analysephase Version

31 Software Engineering I
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 Hauptrichtungen z Daten (Betrachtung der Ein- und Ausgabeflüsse) z Prozesse und Verarbeitungsfunktionen z Information Engineering „Der Schwerpunkt liegt auf den Informationsanforderungen einer Organisation, der Modellierung dieser Informationen und dem Aufbau eines Informationssystems, das auf diesem Modell basiert.“ (James Martin) . Strukturierte Analyse / Strukturiertes Design z Datensicht: Data Model Diagram (Bachman Notation) z Prozess-Sicht: Data Flow Diagram (Gane/Sarson Notation) z Steuerungssicht: Finite State Machine Software Engineering I VE 08: Analysephase Version

32 Systemlayout SA/SD vs. OOAD
Function Function Function Function Data Data Function Function Data Function Function Grundlegende Unterschiede Strukturiertes zu Objektorientiertem Design Software Engineering I VE 08: Analysephase Version

33 SA/SD: Funktionsbaum  DFD
SD: Transformation der DFD-Prozesse in hierarchisch strukturierte Funktionen Abbildung von DFD-Prozessen auf Funktionsstrukturen herstellbar! Software Engineering I VE 08: Analysephase Version

34 SD: Transformation Analyse  Design
B D E F G C H K Do job A B C G F E D K H From data flow diagrams to structure charts: Creative Process! result of SA: logical model, consisting of a set of DFD’s, augmented by minispecs, data dictionary, etc. Structured Design = transition from DFD’s to structure charts heuristics for this transition are based on notions of coupling and cohesion major heuristic concerns choice for top-level structure chart, most often: transform-centered Bei Vorlage von Kontext- und Datenflußdiagrammen mit Prozeßspezifikation aus der „Structured Analysis“ kann man sich im „Structured Design“ an diesen Vorgaben orientieren. Die funktionale Abstraktion muss mit Kreativität und Erfahrung erreicht werden. Mit Einsatz eines SE-Tools kann man jedoch beim Software-Design auf die Prozesse und Datenflüsse der Analyse referenzieren. Auch die Aufrufparameter können aus dem bereits existierenden Data Dictionary bezogen bzw. ergänzt werden. Eine andere Möglichkeit besteht darin, eine Transformation einer Strukturierten Analyse (SA) in ein Strukturiertes Design (SD) durchzuführen. Diese Vorgehensweise beinhaltet Handlungsempfehlungen, ersetzt jedoch keines Falls die bereits mehrfach erwähnte Kreativität und Erfahrung. Software Engineering I VE 08: Analysephase Version

35 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? SA/SD ist ein kreativer, nicht formalisierbarer Prozess! Software Engineering I VE 08: Analysephase Version

36 Beispiel Strukturierte Analyse
Seminarverwaltung Software Engineering I VE 08: Analysephase Version

37 Beispiel SA: Kontextdiagramm
• Schnittstellen sind Stellen, an denen das System Daten mit seiner Umwelt austauscht (Datenquelle, Datensenke). • Anwendungsbereich des Systems = Angabe aller Schnittstellen • Je Schnittstelle: – Name – Datenflüsse zum/vom System (Richtung, Name) – Keine Datenflüsse zwischen Schnittstellen • Schnittstellen werden im Kontextdiagramm beschrieben • Kontextdiagramm: – ist der einfachste Fall eines DFD – besitzt nur eine Funktion für das Gesamtsystem (Ebene 0) – zeigt alle Schnittstellen – beschreibt keine Speicher Software Engineering I VE 08: Analysephase Version

38 Software Engineering I
Beispiel SA: DFD Ebene 0 Hierarchische Zerlegung der Systemfunktionalität • Ebene 0-Diagramm zerlegt das System in eine erste Schicht von Teilfunktionen • Kontextdiagramm und Ebene-0-Diagramm in SA zusammen sind sehr ähnlich zu den Use-Case-Diagrammen von UML. • Ziel ist die hierarchische Funktions-Verfeinerung – Die einzige Funktion der Ebene 0 enthält Unterfunktionen 1, 2, 3, ... – Funktion i enthält Unterfunktionen i.1, i.2, i.3, ... – Aus der Praxis motiviert: Maximal ca. 3 Ebenen – Idealerweise: max. 7 Unterfunktionen • Hierarchie ist Übersichtshilfe – Nicht vergleichbar mit Prozedurkonzept – Keine Sichtbarkeitsbegrenzung Software Engineering I VE 08: Analysephase Version

39 Beispiel SA: DFD Ebene 0 mit Speicher
Speicher im Datenfluss • Funktionen haben in SA ein "Gedächtnis" (Datenbank, Objekte) • Speicher repräsentieren Gedächtnis – Pfeil mit Datenfluss in Speicher ist Schreiben – Pfeil mit Datenfluss aus Speicher ist Lesen • Speicher wird zu Funktionen zugeordnet: – Speicher s wird auf Ebene i definiert – Speicher s steht Funktionen i.xxxx zur Verfügung • Datenfluss drückt benötigte oder gelieferte Daten einer Funktion aus • Datenfluss ist statisch, nicht verwechseln mit Kontrollfluss! – So muss eine Funktion die zur Verfügung stehenden Speicher nicht nutzen – Die Reihenfolge der Funktionsaufrufe ist damit noch keineswegs festgelegt – Tatsächlich: für komplexere Datenflüsse empfiehlt sich die Konzentration des Ablaufwissens in eigenständige Komponenten („Sachbearbeiter“, „Steuerungsobjekte“) Software Engineering I VE 08: Analysephase Version

40 Beispiel SA: DFD Verfeinerung (Ebene 1)
Software Engineering I VE 08: Analysephase Version

41 Beispiel SA: DD und DFD (Ausschnitt)
Software Engineering I VE 08: Analysephase Version

42 Software Engineering I
Beispiel SA: MiniSpec Software Engineering I VE 08: Analysephase Version

43 Entity Relationship Diagramme
ERD Entity Relationship Diagramme Software Engineering I VE 08: Analysephase Version

44 Entity-Relationship Modellierung (ERD)
Ziel ist die Beschreibung von Gegenständen (Entities, Objekte) Beziehungen (Relationships) Eigenschaften (Attribute) ER-Modell wird aufgebaut, um Anwendungsdaten zu strukturieren und zu analysieren Oft werden daraus Datenbanktabellen aufgebaut Modellierung erfolgt über ER-/EER-Diagramme Gute Modellierungstools verfügbar Entität Beziehung Attribut Software Engineering I VE 08: Analysephase Version

45 ERD: Grundlegende Begriffe
Software Engineering I VE 08: Analysephase Version

46 Entity-Relationship Diagramm (ERD)
B (1,1) (0,n) R 0 bis n Genau 1 „Jedes A hat 0 bis n Beziehungen zu einem B“ ! (n,m) legt das Minimum und Maximum der Anzahl Beziehungen des angegebenen Typs fest, die ein Objekt haben kann. Möglich und üblich sind: (0,1) höchstens 1 (1,1) genau eins (n,m) zwischen n und m mit n,m >= 0 (* für unbekannte Obergrenze) Software Engineering I VE 08: Analysephase Version

47 Software Engineering I
ERD: Beispiel Kunden Preis #PosNr Menge bekommt Rechnung enthält Rechnungs- positionen kommt vor in Name #KdNr Adresse Artikel Grösse #ArtNr Farbe interessiert an (0,*) (1,1) (1,*) Software Engineering I VE 08: Analysephase Version

48 Software Engineering I
Übungen Übungen Software Engineering I VE 08: Analysephase Version

49 Software Engineering I
Übung: Pflichtenheft Gegeben seien einige Ausschnitte aus einem Pflichtenheft gemäß dem vorgestellten Pflichtenheft-Muster. Untersuchen Sie diese Ausschnitte auf Fehler. 1 Visionen und Ziele /V10/ Das Produkt dient der Kunden- und Mitarbeiterverwaltung eines Unternehmens. 2 Rahmenbedingungen /R10/ kommerzieller Anwendungsbereich /R20/ Zielgruppe Mitarbeiter des Unternehmens, speziell Verwaltungskräfte 3 Kontext und Überblick /K10/ Zielgruppe sind Mitarbeiter des Unternehmens, speziell Verwaltungskräfte /K20/ Einsatz in Büroumgebung 4 Funktionale Anforderungen /F10/ Verwalten der Mitarbeiter mit Adressen und Gehältern /F20/ Verwalten der Kunden (Firmen und Privatkunden) mit Adressen, Umsatzdaten und Bestellverhalten /F30/ Schnittstellen zu gängiger Bürosoftware (Serienbriefe) /F40/ Typische Listenabfragen /F50/ Typische Reportausgaben /D10/ Zu einem Kunden sind folgende Daten zu speichern: Adresse, Kontakte (Telefon, Fax, ), typische Zahlungsweise: Seminaranfang, Seminarende, monatlich mehrere Einzelrechungen 5 Qualitätsanforderungen /Q10/ Das Produkt soll qualitativ hochwertig sein. /Q20/ Alle gängigen Betriebssysteme müssen unterstützt werden /Q30/ Alle gängigen Rechnerplattformen müssen unterstützt werden /Q40/ Schnittstellen zu gängiger Windows-Software /L10/ Die Bearbeitungszeit aller Funktionen darf nicht über 100ms liegen. /L20/ Die Funktion "Ausdrucken" soll möglichst schnell arbeiten. /L30/ Die Kundendaten aus /D10/ sollen ohne sichtbaren Zeitverzug gelöscht werden können. 6 Abnahmekriterien /A10/Gültiges Abnahmeszenario: Einen Kunden erfassen, einen Mitarbeiter erfassen, Software Engineering I VE 08: Analysephase Version

50 Übung 1: Datenflussdiagramm
Zeichnen Sie ein Datenflussdiagramm, das den Seminarverwaltungsteil einer Seminarorganisation beschreibt. Berücksichtigen Sie die folgenden funktionalen Anforderungen: /F10/ Informieren (von Anfrage bis Auskunft) /F20/ Veranstaltung durchführen /F30/ Dozenten akquirieren Berücksichtigen Sie außerdem die folgenden Daten-Anforderungen: /D10/ Seminartyp /D20/ Seminarveranstaltung /D30/ Dozent Software Engineering I VE 08: Analysephase Version

51 Übung 2: Datenflussdiagramm
Zeichnen Sie ein Datenflussdiagramm zur Verwaltung einer Arztpraxis. Neue Patienten werden in eine Patientenkartei aufgenommen, an der auch später noch Änderungen vorgenommen werden können. Erscheint ein Patient zur Behandlung, so werden dem behandelnden Arzt die Patientendaten und die Daten der letzten Behandlungen zur Verfügung gestellt. Nach der Behandlung werden das Datum, die erbrachten Leistungen und die Verordnungen gespeichert Software Engineering I VE 08: Analysephase Version

52 Übung 1: Datenflussdiagramm
Zeichnen Sie ein Datenflussdiagramm zur Beschreibung des „Generic Assessment Tool“. Berücksichtigen Sie die folgenden funktionalen Anforderungen: /F10/ Assessment Modelle anlegen und verwalten /F20/ Audit-Projekte anlegen und verwalten /F30/ Auditoren anlegen und verwalten /F40/ Audit-Projekt durchführen und auswerten Berücksichtigen Sie die folgenden Daten-Anforderungen: /D10/ Assessment-Modell /D20/ Audit-Projekt /D30/ Auditor /D40/ Auditiertes System Software Engineering I VE 08: Analysephase Version