Die Definitionsphase (Analyse)

1. Die Definitionsphase(Analyse)

2. Vorlesungsinhalt • Einführung Definitionsphase • Modelle und Modellierung • Pflichtenheft • Strukturierte Analyse (SA) • Moderne Strukturierte Analyse

3. Die Definitionsphase Ziel der Definitionsphase ist die • vollständige • konsistente • eindeutige Definition des zu realisierenden Produkts durch den Aufbau eines Produktmodells.

4. Das Produktmodell • Pflichtenheft • Analysemodell • Prototypen

5. 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)!

6. Das Pflichtenheft • Form: • Standardisiertes, gegliedertes Schema, • meistens: textuelle Beschreibung • besser: Beschreibung durch Diagramme • Sprache: • detaillierte verbale Beschreibung (falls textuell), für AG lesbar! • Zeitpunkt: • direkt nach Planungsphase • Umfang: • ausführlich, vollständig

7. Aufbau des Pflichtenheftes (1) • 1. Zielbestimmung • Muß-Kriterien: Was muß das Produkt leisten? • Wunschkriterien: Was soll das Produkt evtl. noch leisten? • Abgrenzungskriterien: Was soll das Produkt nicht leisten? • 2. Produkt-Einsatz • definiert Anwendungsbereiche (wofür), • Zielgruppen (für wen) und • Betriebsbedingungen (z.B. physikalische Umgebung, Betriebszeiten, Betriebspersonal etc.)

8. Aufbau Pflichtenheft (2) • 3. Produkt-Übersicht • Use Case Diagramme • 4. Produkt-Funktionen • Definition der funktionalen Anforderungen • Gliederungsschema (z.B. /F10/ oder /F20/W für Wunschkriterium) mit Bezug zum Lastenheft • TemplatebasierteUse Case Beschreibungen, Aktivitätsdiagramme, Interaktionsdiagramme

9. Aufbau Pflichtenheft (3) • 5. Produkt-Daten • Beschreibung persistenter Daten • Gliederungsschema (z.B. /D10/) mit Bezug zum Lastenheft • Diagramme (ER-Diagramm, Klassendiagramm) • 6. Produkt-Leistungen (vgl. Lastenheft) • 7. Qualitäts-Zielbestimmung (vgl. Lastenheft) • 8. Benutzungsoberfläche (falls gewünscht) • z.B. Fensterlayout, Dialogstruktur etc.

10. Aufbau Pflichtenheft (4) • 9. Globale Testszenarien/Testfälle • Abnahmetest! • 10. Technische Produktumgebung, Schnittstellen zu anderen Systemen • 11. Entwicklungsumgebung • 12. Ergänzungen • 13. Glossar (vgl. Lastenheft)

11. Methodik zur Erstellung des Produktmodells (1) • (Iterative) Erstellung des Pflichtenheftes • Auswahl der einzusetzenden Methoden • Iterative Erstellung eines Produktmodells unter Einsatz der gewählten Methoden (auf Basis des Pflichtenhefts) • Iterative Konzeption der Benutzungsoberfläche, ggf. Erstellung eines entsprechenden Prototyps (auf Basis des Pflichtenhefts)

12. Methodik zur Erstellung des Produktmodells (2) • Erstellung einer ersten Version des Benutzerhandbuches (auf Basis des Pflichtenhefts) • Sich neu ergebende Fragen werden zunächst in einer Liste gesammelt und dann mit dem Auftraggeber besprochen Rückkopplung zum Pflichtenheft ? Change Management ?

13. Structured Analysis (SA) • Analysemethode, die von Tom de Marco eingeführt wurde. • Eingesetzte Basismethoden: • Datenflußdiagramme • Mini Specs • Data Dictionary • (Funktionsbaum)

14. Funktionsbaum • Eine Funktion beschreibt eine Tätigkeit oder eine klar umrissene Aufgabe innerhalb eines größeren Zusammenhangs. • Ein Funktionsbaum ist die Darstellung einer funktionalen Hierarchie durch Gliederung nach Teil-Funktionen. • Funktionsbäume werden in Analyse und Design als Hilfsmittel eingesetzt

15. Schema von Funktionsbäumen • Besteht-aus-Hierarchie (meist in der Definitionsphase): • A besteht aus B und C • Ruft-auf-Hierarchie (meist in der Entwurfsphase): • A ruft B und C auf. • Erstellungsregeln: • Unter einer gemeinsamen Vaterfunktion sollen nur Funktionen angeordnet sein, die fachlich eng zusammengehörende Tätigkeiten beschreiben. • Auf einer Hierarchieebene sollen Funktionen angeordnet sein, die sich auf gleichem Abstraktionsniveau befinden. A B C

16. Datenflussdiagramm (DFD) • DFD beschreiben die Wege von Daten zwischen Funktionen, Speichern und Schnittstellen sowie die Transformation der Daten durch die Funktionen

17. Basiselemente Beschreibt den Datenfluß mit Daten“typ“ Beschreibt eine Funktion Beschreibt einen Datenspeicher Beschreibt eine Schnittstelle zur Umwelt

18. Beispiel (Kontextdiagramm) Anfragen Kundendaten Kundenverwaltungssystem 0 Kundensach- bearbeiter Kunde Auskünfte Mitteilungen Firmendaten Firma Mitteilungen

19. Beispiel (DFD0) Kundendaten Firmendaten Beantworte Anfragen 3 Verwalte Kundendaten 1 Anfragen Kundendaten Mitteilungen Auskünfte Verwalte Firmendaten 2 Firmendaten Mitteilungen

20. Syntaktische Regeln • Ein DFD enthält mindestens eine Schnittstelle • Jede Schnittstelle wird i.a. nur einmal dargestellt • Zwischen Schnittstellen gibt es keine direkten Datenflüsse • Zwischen Speichern gibt es keine direkten Datenflüsse • Zwischen Schnittstellen und Speichern gibt es keine direkten Datenflüsse

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

22. Kontextdiagramm • Das Kontextdiagramm beschreibt die Schnittstellen des zu modellierenden Systems zur Umwelt. • Das System wird als Funktion mit der Nummer 0 dargestellt, ansonsten sind nur Schnittstellen und Datenflüsse zwischen den Schnittstellen und dem System zulässig.

23. Verfeinerung • Das Kontextdiagramm wird durch das DFD0 (Datenflußdiagramm zur Funktion 0) verfeinert. • Hier findet man die Funktionen auf höchster Ebene (im Funktionsbaum auf Level 1) • Die Funktionen werden detaillierter beschrieben durch weitere Datenfluß-diagramme (DFD n für Funktion n) oder durch Mini Specs

24. Mini Specs • 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

25. Data Dictionary 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* DD ist ein Verzeichnis, das Informationen über die Struktur von Daten enthält, ihre Eigenschaften und ihre Verwendung enthält

26. Beispiel Kundendatei = {Kundeneintrag} Kundeneintrag = Personal-Nr. + Name + Adresse + (Geburtsdatum) + (Funktion) + Umsatz Name = Anrede + (Titel) + Vorname + Nachname Adresse = [Strasse + Haus-Nr. | Postfachnummer] + (Länderkennzeichen) + PLZ + Ort + (Telefon) + (Fax)

27. Integritätsregeln (1) • In der Structured Analysis 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

28. Integritätsregeln (2) • 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

29. Moderne Strukturierte Analyse • Kombination aus Strukturierter Analyse und Entity Relationship Modellierung bzw. Semantischer Datenmodellierung (und Zustandsmodellierung) • Funktionale Modellierung und Datenmodellierung werden gleichberechtigt betrachtet • Abgleich zwischen funktionalem Modell und Datenmodell wesentlich

30. Entity-Relationship Modellierung • 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-Diagramme

31. Grundlegende Begriffe

32. Entity-Relationship Diagramm Entität Beziehung Attribut A (0,n) (1,1) R B „Jedes A hat 0 bis n Beziehungen zu einem B“ 0 bis n Genau 1 ! (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)

33. Beispiel (0,*) (1,1) Rechnung bekommt Kunden (1,*) Name (0,*) Adresse enthält interessiert an #KdNr Preis (1,1) (0,*) Menge Rechnungs- positionen kommt vor in Artikel (0,*) (1,1) #PosNr Grösse Farbe #ArtNr

34. Semantische Datenmodelle Maschine • Nutzung spezieller Beziehungen: • Aggregation / Komposition • Vererbung IS-A IS-A IS-A Motor Roboter Computer IS-A Part-of Part-of IS-A Auto-Motor Sensor Arm Mein_PC Part-of Greifer

35. Vorgehensweise (1) 1. Ermitteln der Objekttypen 2. Ermittlung der Beziehungen inklusive Kardinalität 3. Zuordnung der Attribute, sofern nicht schon in 1. / 2. geschehen 4. Behandlung von Vererbung

36. Vorgehensweise (2) 5. Zuordnung der Schlüsselkandidaten, sofern möglich 6. Definition von Fremdschlüsseln 7. Auflösung komplexer Beziehungen und Definition der Fremdschlüssel 8. Zuordnung der Schlüsselkandidaten, sofern unter 5. noch nicht möglich 9. Behandlung strukturierter und mengenwertiger Attribute