1 / 36

Die Definitionsphase (Analyse)

Die Definitionsphase (Analyse). Vorlesungsinhalt. Einführung Definitionsphase Modelle und Modellierung Pflichtenheft Strukturierte Analyse (SA) Moderne Strukturierte Analyse. Die Definitionsphase. Ziel der Definitionsphase ist die vollständige konsistente eindeutige

saima
Download Presentation

Die Definitionsphase (Analyse)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related