Konstruktive und Deskriptive Spezifikationen

Marcel Lüthi
Departement Mathematik und Informatik

Klassifikation von Spezifikationsmethoden

Konstruktiv, Deskriptiv

Konstruktive Spezifikation:
Verhalten wird anhand einer "abstrakten Maschine" definiert
Deskriptive Spezifikation:
Verhalten wird anhand von Eigenschaften definiert

Informell, Semiformal, Formal

Wie gesagt können wir zwei Klassen von Methoden für die Spezifikation von Softwaresystemen unterscheiden. Die erste Klasse sind die Konstruktiven Spezifikationsmethoden. Bei diesen Methoden wird das Verhalten der Software anhand einer Ausführungsanweisung spezifiziert. Wir können uns vorstellen, dass wir zumindest theoretisch, eine abstrakte Machine konstruieren könnten, die unsere Spezifikation ausführt. Die zweite Klasse sind die Deskriptiven Spezifikationen. Hier wird nur beschrieben was die Software macht, also was die Eigenschaften sind. Im Gegensatz zu konstruktiven Spezifikationen, wird hier kein Ablauf spezifiziert - es wird nur beschrieben, was gelten muss. Sowohl konstruktive als auch deskriptive Spezifikationen können wir auf unterschiedlichen Formalitätsstufen erstellen. Wir unterscheiden grob zwischen informellen, semiformalen und formalen spezifikationen. Informelle spezifikationen sind meistens spezifikationen in natürlicher Sprache, während formale spezifikationen häufig mathematische formalismen nutzen, oder zumindest eine mathematisch exact definierte semantik haben.

Beispiel: Konstruktive Spezifikation

Spezifikation einer geometrischen Figur $E$.

Bestimme zwei Punkte $P_1$ und $P_2$ einer Ebene
Nimm eine Schnur und befestige die Enden an den Punkten $P_1, P_2$
Nimm einen Bleistift und spanne damit die Schnur
Fahre mit dem Bleistift im Gegenuhrzeigersinn

Schnur muss immer gespannt sein

Beispiel: Deskriptive Spezifikation

Spezifikation einer geometrischen Figur $E$.

Die geometrische Figure $E$ wird durch die folgende Gleichung definiert
\[ \frac{x^2}{a^2} + \frac{y^2}{b^2} = c \] wobei $a, b, c > 0$ zu wählende Konstanten sind

Beispiele wichtiger Spezifikationsmethoden

Datenflussdiagramme

Semi-formale, konstruktive Spezifikation
Systemsicht: Kollektionen von Daten die durch Funktionen "transformiert" werden

Daten/Informationsfluss im Zentrum

Daten können persistent sein

können in Datenspeicher gespeichert sein

Datenflussdiagramme

Diagramm nach Ghezzi et al. Abbildung 5.3

Datenflussdiagramme

Datenflussdiagramm Beispiel

Diagramm nach Ghezzi et al. Abbildung 5.4

Präzisierung

Präzisierung

Präzisierung

Datenflussdiagramm Beispiel

Datenflussdiagramm Beispiel: Präzisierung

Diagramm nach Ghezzi et al. Abbildung 5.5

Vor / Nachteile von Datenflussdiagrammen

Vorteile

Intuitive Semantik, Einfach zu lesen
Kann auch von Kunden verstanden werden
Natürliche Aufteilung in verschiedene Detaillevel

Nachteil
- Keine formale Definition der Semantik

Zusammenfassend kann man sagen, dass Datenflussdiagramme eine sehr einfache und intuitive Art sind, den Datenfluss in einem System zu spezifizieren. Durch die Einfachheit lassen Sie sich auch einfach in der Kommunikation mit einem Kunden einsetzten. Zudem, können wir die Funktionalität auf verschiedenen Detailierungsebenen spezifizieren und somit das System je nach Bedarf sehr abstrakt oder sehr detailliert beschreiben. Ein Nachteil von Datenflussdiagrammen ist aber sicherlich, dass die Semantik nicht genau spezifizieren ist. Während die Notation weitgehend standardisiert ist, fehlen doch viele Details um diese Diagramme präzise interpretieren zu können. Es handelt sich hier eben nur um eine eine Semi-formale spezifikationsmethode.

Unklarheit im Datenfluss

Diagramm nach Ghezzi et al. Fundamentals of Software Engineering, Abbildung 5.6

Braucht D Information von A, B und C?
Gibt D dieselben Daten an E und F?

Unklarheit im Kontrollfluss

Diagramm nach Ghezzi et al., Fundamentals of Software Engineering, Abbildung 5.7

Mögliche Interpretation:

A und B sind sequentielle Funktionen

A produziert Datum für B, wartet bis B es konsumiert

A und B sind autonome Prozesse

A produziert kontinuierlich
B kann Datum mehrmals lesen

Entity Relationship Model

Entität: Individuell identifizierbares Objekt der Wirklichkeit
Wikipedia

Deskriptive Spezifikationsmethode
Vorläufer der UML Klassendiagramme
Drei Kernstrukturen:

Entitäten
Beziehungen zwischen Entitäten
Attribute der Entitäten

Wir kommen nun zu einer zweiten Spezifikationsmethode, nämlich den Entity Relationship Diagrammen. Diese wurden fast zur selben Zeit wie die DAtenflussdiagramme entwickelt. Bei ER Diagrammen handelt es sich aber um eine deskriptive Spezifikationsmethode. ER Diagramm können als Vorläufer der UML Klassendiagramme gesehen werden. Sie zeigen die Beziehung zwischen Etnitäten. Wikipedia definiert den Begriff Entitat als ein individuell identifizierbares Objet der Wirklichkeit. Unter Entitäten verstehen wir im wesentlichen Objekte, die wir in UML als Klassen definieren würden. Jeder Entiät hat verschiedene Attribute die die individuellen Instanzen charakterisieren. Wir sehen hier bereits ein kleines Beispiel eines ER Diagramms. Wir haben zwei Entitäten, nämlich Student und Vorlesung. Als Attribute von Student haben wir Merkmale wie Name Alter oder Geschlecht. Wir sehen auch, dass wir eine Relation zwischen Student und Vorlesung haben.

ERM: Kardinalitäten

Keine standardisierte Notation.

Unterschiedliche Varianten möglich

ERM: Beispiel

Entity Relationship Model

Trotz alter noch sehr populär für Datenmodellierung
Einfach - daher auch für nicht Experten verständlich
Nur Semi-formal
Komplementieren Datenflussdiagramme

Datenflussdiagramm: Operationen auf Daten
Entity Relationship Modelle: Beziehung zwischen Daten

Wie zuvor erwähnt, sind Entity relationship Modelle bereits sehr alte MOdelle. Vor allem in der Datenmodellierung, also zum Beispiel für Datenbankdesign, sind diese Modelle jedoch auch heute noch immer sehr popular, um die Zusammenhänge zwischen den verschiedenen Entitäten zu zeigen. Genau wie Datenflussdiagramme, sind auch diese Diagramme sehr einfach zu verstehen und auch für nicht Experten Verständlich. Jedoch sind auch diese Diagramme nur Semi-formal definiert. Entity Relationship Diagramme sind quasi das Gegenstück zu Datenflussdiagramme. Bei Datenflussidagrammen stehen die Operatinen auf den Daten im Vordergrund, also der Datenfluss und wie die Daten durch das System transformiert werden. ER-Diagrammen hingegen beschreiben welche Entitäten, und somit welche Daten, zusammen in Beziehung stehen.

Endliche Automaten (Finite State Machines)

Formale, konstruktive Methode

Menge von Zuständen $Q$
Menge von Inputs $I$
Transitionsfunktion: $\phi : Q \times I \to Q$
Startzustand $s \in Q$

Diagramm nach Ghezzi et al., Fundamentals of Software Engineering, Abbildung 5.12

Als letztes schauen wir uns noch kurz eine sehr wichtige, konstruktive Methode an, nämlich die Endlichen Automaten. Mit endlichen Automaten modellieren wir zustände in einem System. Es handelt sich hier um eine konstruktive, formale methode. Die Beschreibung ist präzise genug, dass wir direkt eine entsprechende Implementation schreiben könnten, um die Spezifikation zu simulieren . Um einen endlichen Automaten zu spezifizieren, definieren wir die Menge von möglichen Zuständen Q, eine Menge on möglichen Inputs I, sowie eine Transitionsfunktion. Die Transitionsfuktion definiert für jeden möglichen Zustand und jeden möglichen Input im System, in welchen Zustand das System wechseln wird. Damit wir das System starten können, müssen wir auch noch einen Anfangszustand definieren. Auch endliche Automaten haben eine graphische Darstellung. In diesem Beispiel hier sehen wir 4 mögliche Zustände, q_0 bis q_4 und3 Mögliche Inputs, a b und z. Die Kanten im Graphen repräsentieren die Transistionsfunktion. Wenn wri beispielsweise in Zustand q_1 sind und den Input a sehen, wechseln wir in Zsutand q_2. Bei input b wechseln wir in zustand q_4.

Beispiel: Endliche Automaten

Das vielleicht einfachste praktische Beispie eines endlichen Automaten ist ein einfacher Schalter. Wenn das Licht aus ist, und wir den Schalter drücken, dann geht das licht an. Wenn das Licht an ist und wir den schalter drücken, geht das Licht wieder aus. Wir haben hier also nur Zwei Zustände, an und aus, und einen möglichen Input, nämlich schalter gedrückt. Wir werden spáter diese Woche sehen, dass endliche Automaten, zusammen mit zwei anderen formalen Spezifikationsmethoden, die wir im folgenden Anschauen werden, auch Grundlage von einigen Spezifikationsmethoden der UML Familie sind.

Konstruktive und Deskriptive Spezifikationen

Marcel Lüthi Departement Mathematik und Informatik

Klassifikation von Spezifikationsmethoden

Beispiel: Konstruktive Spezifikation

Beispiel: Deskriptive Spezifikation

Beispiele wichtiger Spezifikationsmethoden

Datenflussdiagramme

Datenflussdiagramme

Datenflussdiagramme

Datenflussdiagramm Beispiel

Präzisierung

Präzisierung

Präzisierung

Datenflussdiagramm Beispiel

Datenflussdiagramm Beispiel: Präzisierung

Vor / Nachteile von Datenflussdiagrammen

Unklarheit im Datenfluss

Unklarheit im Kontrollfluss

Entity Relationship Model

ERM: Kardinalitäten

ERM: Beispiel

Entity Relationship Model

Endliche Automaten (Finite State Machines)

Beispiel: Endliche Automaten

Marcel Lüthi
Departement Mathematik und Informatik