Traditionelle „strukturierte“ Spezifikationsmethoden
Transcription
Traditionelle „strukturierte“ Spezifikationsmethoden
Traditionelle „strukturierte“ Spezifikationsmethoden Bekannte Ansätze ✩ Datenmodellierung (Entity-Relationship-Modelle) ✩ Strukturierte Analyse ✩ "Moderne Strukturierte" Analyse, SA/RT ✩ SADT Requirements Engineering: Strukturierte Spezifikationsmethoden M. Glinz WS 2000/01 1 Datenmodellierung ❏ Grundlage: Entity-Relationship Ansatz (Chen 1976) ❏ modelliert einen Ausschnitt der Realität mit Hilfe von Gegenstandstypen (entity types), Beziehungstypen (relationship types) und Attributen (attributes) arbeitet in Person Abteilung ist beteiligt an Projekt + + Einfach und klar Leicht auf Datenbank-Realisierungen abbildbar – – – – Ignoriert Funktionalität und Verhalten der Systeme Keine Mittel zur Systemdekomposition Keine Lokalität oder Einkapselung von Daten Kümmert sich nicht um Wiederverwendung Requirements Engineering: Strukturierte Spezifikationsmethoden M. Glinz WS 2000/01 2 Strukturierte Analyse ✩ Modelliert die Funktionalität eines Systems mit Hilfe von Datenflussdiagrammen (DeMarco 1978, Gane und Sarson 1979) Anzeige Rohwert Grenzwerte Messwert dimensionieren Messwert Dimension Messwert Grenzwerte prüfen AlarmIndikator Instrumentanzeige aufbauen InstrumentBilder ❍ Teilformale, konstruktive Spezifikationsmethode ❍ Basiert auf dem Prinzip der datengesteuerten Verarbeitung: Jede Aktivität arbeitet dann, wenn die von ihr benötigten Daten eintreffen ❍ Datenflussdiagramme sind hierarchisch strukturiert Requirements Engineering: Strukturierte Spezifikationsmethoden M. Glinz WS 2000/01 3 Grundkonzepte der Strukturierten Analyse DatenflußDiagramm(e) Gast := Name + Vorname + Adresse Name := {Zeichen} ... Datenlexikon SA Zimmer reservieren WENN Zimmer der gewünschten Art ist frei DANN... ..... MiniSpezifikationen Dekomposition Requirements Engineering: Strukturierte Spezifikationsmethoden M. Glinz WS 2000/01 4 Notation für Datenflussdiagramme (links: DeMarco, rechts: Gane und Sarson) Aktivität (Prozess; activity, process) Datenfluss (dataflow) Speicher (store, file) Endknoten (terminator, terminal, external) Interpretation von Datenflussdiagrammen ❏ Datenflüsse transportieren Datenpakete, die von Aktivitäten oder Endknoten produziert bzw. konsumiert werden. ❏ Aktivitäten arbeiten nur dann, wenn alle von ihnen benötigten Eingabe-Datenflüsse vorliegen. Die Aktivität konsumiert die Daten, bearbeitet sie und produziert AusgabeDatenflüsse. Sie kann dabei zusätzlich Speicherinhalte lesen oder schreiben. ❏ Speicher modellieren Datenbehälter. Ihr Inhalt kann gelesen werden (ohne den Speicher zu verändern) und geschrieben werden (dabei wird der alte Inhalt zerstört). ❏ Endknoten sind Aktivitäten in der Systemumgebung. Requirements Engineering: Strukturierte Spezifikationsmethoden M. Glinz WS 2000/01 5 ❍ Datenflussdiagramme sind Übersichtsmodelle ❍ Zur Präzisierung müssen definiert werden: ❍ die Namen aller Datenflüsse und Speicher ->Datenlexikon ❍ die Funktionalität jeder nicht hierarchisch zerlegten Aktivität -> Mini-Spezifikationen Requirements Engineering: Strukturierte Spezifikationsmethoden M. Glinz WS 2000/01 6 Das Datenlexikon Definiert alle im Modell verwendeten Datennamen ❍ Gebräuchliche Notation: a = expr (oder a := expr) "<zeichenfolge>" Stelle a wird durch den Ausdruck expr definiert Literal. <zeichenfolge> muss wörtlich an der betreffenden vorkommen *<text>* <text> ist ein Text, der als informale Definition oder als Erläuterung dient ❍ Elementardefinitionen: Ein Datum wird durch einen Text oder ein Literal definiert ❍ Strukturdefinitionen: c=a+b c=[a|b] c = n{a}m c = {a} c = (a) c ist zusammengesetzt aus a und b c ist entweder a oder b c ist eine n- bis m-fache Wiederholung von a äquivalent mit 0{a}∞ äquivalent mit 0{a}1, (d.h. a ist optional) a, b, c: Namen oder Elementardefinitionen ❍ Eine Definition kann zusätzlich durch Texte annotiert werden Requirements Engineering: Strukturierte Spezifikationsmethoden M. Glinz WS 2000/01 7 Beispiele Reservierungswunsch := Anzahl + Zimmerart + ResVon + ResBis + Name *erwartete Angaben für eine Reservation*. Anzahl := * 1..N * *Anzahl der bestellten Zimmer*. Zimmerart := [ "EZ" | "DZ" | "EZmitDuWC" | "DZmitDuWC" ] *Art der bestellten Zimmer *. Name := {Zeichenkette} *Name des Gasts, für den reserviert wird*. Requirements Engineering: Strukturierte Spezifikationsmethoden M. Glinz WS 2000/01 8 Mini-Spezifikationen ❍ Elementare, nicht weiter zerlegte Spezifikation einer Aktivität ❍ Beschreibt den geforderten Zusammenhang zwischen den Eingabe- und den Ausgabedaten einer Aktivität ❍ Mögliche Darstellungsformen ❍ ❍ Informale Beschreibung mit Text ❍ Pseudocode ❍ Formale Ergebnisbeschreibung mit mathematischen Formeln ❍ Teilformale Ergebnisbeschreibung (kein Ablauf, nur geforderte Resultate) ❍ Entscheidungstabellen Wahl der Darstellungsform je nach Problemstellung Requirements Engineering: Strukturierte Spezifikationsmethoden M. Glinz WS 2000/01 9 Hierarchische Zerlegung ❍ Eine Aktivität kann wiederum durch ein Datenflussdiagramm beschrieben werden -> DFD-Hierarchie ❍ Ebenen müssen konsistent (balanciert) sein ❍ An der Spitze der Hierarachie steht ein Kontextdiagramm Kontext-Diagramm 0 DFD 0 3 2 1 DFD 1 .2 DFD 3 .3 .3 .2 .4 .1 .1 Requirements Engineering: Strukturierte Spezifikationsmethoden M. Glinz WS 2000/01 10 Methodik der Modellierung Essentielle Systemanalyse (McMenamin und Palmer 1984) Klassisches Vorgehen: 1 Erstelle ein Kontextdiagramm 2 Erstelle eine Ereignisliste (Ereignis = Anstoß aus der Außenwelt, der eine Reaktion des Systems erfordert) 3 ❏ ❏ ❏ ❏ Zeichne ein DFD mit einer Aktivität für jeden Vorgang (Vorgang = Verarbeitung eines Ereignisses und Erzeugung der erwarteten Reaktionen) Schließe interaktiv die dabei auftretenden Informationslücken Definiere die verwendeten Daten Skizziere Mini-Spezifikationen 4 Restrukturiere dieses (in der Regel sehr große) DFD in eine Hierarchie 5 Vervollständige das Modell Requirements Engineering: Strukturierte Spezifikationsmethoden M. Glinz WS 2000/01 11 Problem: ergibt große, schwach strukturierte DFD, keine Lokalität oder Kapselung möglich ➬ besseres Vorgehen: 2' ❏ ❏ ❏ Gliedere die Aufgabe in Teile, die (soweit wie möglich) in sich geschlossen sind Erstelle die Ereignisliste Bilde Unter-Ereignislisten für jede Teilaufgabe 3' Arbeite gemäß 3 für jede Teilaufgabe; stimme dabei das Neue auf schon vorhandene Teilmodelle ab 4' Arbeite gemäß 4 für jede Teilaufgabe (falls nötig) 5' Arbeite gemäß 5 und synthetisiere die oberste(n) Zerlegungsebene(n) aus den TeilModellen Requirements Engineering: Strukturierte Spezifikationsmethoden M. Glinz WS 2000/01 12 Schwächen der „reinen“ Strukturierten Analyse ✩ Zusammenhänge zwischen Datenspeichern nicht modellierbar ➥ Verbindung mit Entity-Relationship-Diagrammen (Chen 1976) ❍ Jeder Speicher ist Gegenstandstyp eines Entity-Relationship-Diagramms ✩ Zeit- und zustandsabhängiges Verhalten nicht modellierbar ➥ Verbindung mit Zustandsautomaten (meistens SA/RT genannt, RT steht für Real Time; Hatley und Pirbhai 1988, Ward und Mellor 1985) ➔ ❍ Zwei zusätzliche Modell-Elemente: – Steuerflüsse (gestrichelter Pfeil im DFD) – Steuerspezifikationen (fette Linie oder gestrichelter Kreis im DFD) ❍ Steuerspezifikationen beschreiben das dynamische Verhalten mit Zustandsautomaten und die zugehörigen Aktivitäten im DFD mit Aktivierungstabellen ❍ Steuerflüsse transportieren die Ereignisse, welche die Zustandsautomaten steuern oder dort erzeugt werden Sogenannte Moderne Strukturierte Analyse oder SA mit Erweiterungen (Yourdon 1989) Requirements Engineering: Strukturierte Spezifikationsmethoden M. Glinz WS 2000/01 13 Stärken und Schwächen der Strukturierten Analyse (u.a. Glinz 1991) + Sehr anschaulich + Datenfluss ist ein natürliches Operationsprinzip für viele Probleme + Unterstützt Systemdekomposition – Strukturbruch zwischen Spezifikation und Implementierung – Keine Lokalität von Daten; Einkapselung nur begrenzt möglich – keine integrierte Modellierung von Daten, Funktionen und zeitlichem Verhalten; stattdessen Patchwork von Datenfluss-, Entity-Relationship- und Zustandsdiagrammen – Mittel zur Datendefinition umständlich und veraltet – Einbettung in vorhandene Software nur schwer modellierbar ✩ (Erweiterte) Strukturierte Analyse war das Verfahren der 80er Jahre ✩ Wird langsam aber sicher durch objektorientierte Verfahren verdrängt Requirements Engineering: Strukturierte Spezifikationsmethoden M. Glinz WS 2000/01 14 SADT SADT: Structured Analysis and Design Technique (Ross, 1977) ≠ Strukturierte Analyse (Structured Analysis nach DeMarco, Gane und Sarson, McMenamin und Palmer, etc.) ✩ Zwei Diagrammtypen ✧ Aktivitätsdiagramme ✧ Datendiagramme ✩ Hierarchische Zerlegung ✩ Wird praktisch nicht mehr verwendet Requirements Engineering: Strukturierte Spezifikationsmethoden M. Glinz WS 2000/01 15 Aktivitätsdiagramme ❍ Aktivitäten sind die zentralen Modellelemente ❍ Aktivitäten durch Datenflüsse verbunden/angestoßen -> Ähnlich wie Datenflussdiagramme ❍ Zusätzlich werden Steuerflüsse und Mechanismen modelliert ❍ Datenfluss streng von links nach rechts Steuerdaten Eingabedaten Ausgabedaten Aktivität Ressourcen, Mechanismen Requirements Engineering: Strukturierte Spezifikationsmethoden M. Glinz WS 2000/01 16 Datendiagramme ❍ Daten sind die zentralen Modellelemente ❍ Flüsse modellieren primär Erzeugung und Verwendung von Daten ❍ Ferner werden Steuerinformationen und Speichermedien modelliert Steuernde Aktivität(en) Erzeugende Aktivität(en) Verwendende Aktivität(en) Datum Speichermedium Requirements Engineering: Strukturierte Spezifikationsmethoden M. Glinz WS 2000/01 17 Literatur Chen, P.P. (1976) The Entity-Relationship Model -Toward a Unified View of Data. ACM Transactions on Database Systems 1, 1 (March 1976). 9-36. DeMarco, T. (1978). Structured Analysis and System Specification. Yourdon Press, New York. Gane C., T. Sarson (1979). Structured Systems Analysis: Tools and Techniques. Prentice-Hall, Englewood Cliffs, N.J. Glinz, M. (1991). Probleme und Schwachstellen der Strukturierten Analyse. In Timm, M. (Hrsg.): Requirements Engineering '91. Informatik-Fachberichte Band 273, Berlin, etc.: Springer. 14-39. Hatley, D.J., I.A. Pirbhai (1988). Strategies for Real-Time System Specification. Dorset House, New York. McMenamin, S.M., J.F. Palmer (1984). Essential Systems Analysis. Yourdon Press, New York. Ross, D. (1977). Structured Analysis (SA): A Language for Communicating Ideas. IEEE Transactions on Software Engineering, SE-3, 1 (Jan. 1977). 16-34. Ward, P.T., S.J. Mellor (1985). Structured Development for Real-Time Systems, Vol. I-III. Prentice-Hall, Englewood Cliffs, N.J. Yourdon, E. (1989). Modern Structured Analysis. Prentice-Hall, Englewood Cliffs, N.J. 672 p. Requirements Engineering: Strukturierte Spezifikationsmethoden M. Glinz WS 2000/01 18