Vienna Development Method (VDM) ist eine der am längsten gegründeten Formellen Methoden für die Entwicklung von computergestützten Systemen. In der geleisteten Arbeit am Wiener Laboratorium von IBM in den 1970er Jahren entstehend, ist es gewachsen, um eine Gruppe von Techniken und Werkzeugen einzuschließen, die auf einer formellen Spezifizierungssprache - die VDM Spezifizierungssprache (VDM-SL) gestützt sind. Es hat eine verlängerte Form, VDM ++, der das Modellieren von objektorientierten und gleichzeitigen Systemen unterstützt. Die Unterstützung für VDM schließt kommerzielle und akademische Werkzeuge ein, um Modelle einschließlich der Unterstützung zu analysieren, um Eigenschaften von Modellen zu prüfen und zu beweisen und Programm-Code von gültig gemachten VDM Modellen zu erzeugen. Es gibt eine Geschichte des Industriegebrauchs von VDM und seinen Werkzeugen, und ein wachsender Körper der Forschung im Formalismus hat zu bemerkenswerten Beiträgen zur Technik von kritischen Systemen, Bearbeitern, gleichzeitigen Systemen und in der Logik für die Informatik geführt.

Philosophie

Rechensysteme können in VDM-SL an einem höheren Niveau der Abstraktion modelliert werden, als erreichbare Verwenden-Programmiersprachen ist, die Analyse von Designs und Identifizierung von Hauptmerkmalen einschließlich Defekte in einer frühen Bühne der Systementwicklung erlaubend. Modelle, die gültig gemacht worden sind, können in ausführliche Systemdesigns durch einen Verbesserungsprozess umgestaltet werden. Die Sprache hat eine formelle Semantik, Beweis der Eigenschaften von Modellen zu einem hohen Niveau der Versicherung ermöglichend. Es hat auch eine rechtskräftige Teilmenge, so dass Modelle durch die Prüfung analysiert werden können und durch grafische Benutzerschnittstellen durchgeführt werden können, so dass Modelle von Experten bewertet werden können, die mit der Modellieren-Sprache selbst nicht notwendigerweise vertraut sind.

Geschichte

Die Ursprünge von VDM-SL liegen in IBM Laboratory in Wien, wo die erste Version der Sprache Vienna Definition Language (VDL) genannt wurde. Der VDL wurde im Wesentlichen verwendet, um betriebliche Semantik-Beschreibungen im Gegensatz zum VDM - Meta-IV zu geben, der denotational Semantik zur Verfügung gestellt

hat

"Zum Ende von 1972 hat die Wiener Gruppe wieder ihre Aufmerksamkeit auf das Problem gelenkt, systematisch einen Bearbeiter aus einer Sprachdefinition zu entwickeln. Die gesamte angenommene Annäherung ist die "Wiener Entwicklungsmethode" genannt worden... Die Metasprache hat wirklich ("Meta-IV") angenommen wird verwendet, um Hauptteile von PL/1 (wie gegeben, in ECMA 74 - interessanterweise ein "formelles Standarddokument schriftlich als ein abstrakter Dolmetscher") in BEKIČ 74 zu definieren."

So Meta-IV, wurde "verwendet, um Hauptteile" der PL/I Programmiersprache zu definieren. Andere Programmiersprachen beschrieben, oder haben teilweise mit Meta-IV beschrieben, und VDM-SL schließen die GRUNDLEGENDE Programmiersprache, FORTRAN, die APL Programmiersprache, Algol 60, die Programmiersprache von Ada und die Programmiersprache von Pascal ein. Meta-IV hat sich zu mehreren Varianten entwickelt, die allgemein als die dänischen, englischen und irischen Schulen beschrieben sind.

Die "englische Schule" ist auf Arbeit von Cliff Jones auf den Aspekten von VDM zurückzuführen gewesen, der nicht spezifisch mit der Sprachdefinition und dem Bearbeiter-Design (Jones 1980, 1990) verbunden ist. Es betont modellierenden beharrlichen Staat durch den Gebrauch von von einer reichen Sammlung von Grundtypen gebauten Datentypen. Funktionalität wird normalerweise durch Operationen beschrieben, die Nebenwirkungen auf dem Staat haben können, und die größtenteils implizit mit einer Vorbedingung und Postbedingung angegeben werden. Die "dänische Schule" (Bjørner u. a. 1982) hat dazu geneigt, eine konstruktive Annäherung mit der ausführlichen betrieblichen an ein größeres Ausmaß verwendeten Spezifizierung zu betonen. Die Arbeit in der dänischen Schule hat zu gültig gemachtem Bearbeiter von Ada des ersten Europäers geführt.

Ein ISO Standard für die Sprache wurde 1996 (ISO, 1996) veröffentlicht.

VDM Eigenschaften

Der VDM-SL und VDM ++ Syntax und Semantik werden ausführlich in den VDMTools Sprachhandbüchern und in den verfügbaren Texten beschrieben. Der ISO Standard enthält eine formelle Definition der Semantik der Sprache. Im Rest dieses Artikels der ISO-definierte Austausch (ASCII) wird Syntax verwendet. Einige Texte bevorzugen eine kürzere mathematische Syntax.

Ein VDM-SL Modell ist eine Systembeschreibung, die in Bezug auf die auf Daten durchgeführte Funktionalität gegeben ist. Es besteht aus einer Reihe von Definitionen von Datentypen und Funktionen oder auf sie durchgeführten Operationen.

Grundlegende Typen: numerisch, Charakter, Jeton und Zitat-Typen

VDM-SL schließt grundlegende Typen ein, Zahlen und Charaktere wie folgt modellierend:

Datentypen werden definiert, um die Hauptdaten des modellierten Systems zu vertreten. Jede Typ-Definition führt einen neuen Typ-Namen ein und gibt eine Darstellung in Bezug auf die grundlegenden Typen oder in Bezug auf bereits eingeführte Typen. Zum Beispiel könnte ein Typ, Benutzerbezeichner für ein Anmeldungsverwaltungssystem modellierend, wie folgt definiert werden:

Typen

UserId = nat

Um Werte zu manipulieren, die Datentypen gehören, werden Maschinenbediener auf den Werten definiert. So, Hinzufügung der natürlichen Zahl, wird Subtraktion usw. zur Verfügung gestellt, wie Maschinenbediener von Boolean wie Gleichheit und Ungleichheit sind. Die Sprache befestigt keine maximale oder minimale wiederpräsentable Zahl oder eine Präzision für reelle Zahlen. Solche Einschränkungen werden definiert, wo sie in jedem Modell mittels des Datentyps invariants — Ausdrücke von Boolean erforderlich sind, die Bedingungen anzeigen, die durch alle Elemente des definierten Typs respektiert werden müssen. Zum Beispiel würde eine Voraussetzung, dass Benutzerbezeichner nicht größer sein müssen als 9999, wie folgt ausgedrückt (wo

UserId = nat

inv uid == uid

Typ-Konstrukteure: Vereinigung, Produkt und zerlegbare Typen

Die grundlegenden Typen allein sind vom beschränkten Wert. Neue, mehr strukturierte Datentypen werden mit Typ-Konstrukteuren gebaut.

Der grundlegendste Typ-Konstrukteur bildet die Vereinigung von zwei vorherbestimmten Typen. Der Typ enthält alle Elemente des Typs A und den ganzen Typ. Im Verkehrssignalkontrolleur-Beispiel konnte der Typ, die Farbe eines Verkehrssignals modellierend, wie folgt definiert werden:

SignalColour =

Aufgezählte Typen in VDM-SL, werden wie gezeigt, oben als Vereinigungen auf Zitat-Typen definiert.

Kartesianische Produkttypen können auch in VDM-SL definiert werden. Der Typ ist der Typ, der aus allen Tupeln von Werten zusammengesetzt ist, von denen das erste Element vom Typ und dem zweiten vom Typ und so weiter ist. Der zerlegbare oder Rekordtyp ist ein Kartesianisches Produkt mit Etiketten für die Felder. Der Typ

T:: f1:A1

f2:A2

...

fn:An

ist das Kartesianische Produkt mit etikettierten Feldern. Ein Element des Typs kann aus seinen konstituierenden Teilen von einem Konstrukteur zusammengesetzt, schriftlich werden. Umgekehrt, in Anbetracht eines Elements des Typs, können die Feldnamen verwendet werden, um den genannten Bestandteil auszuwählen. Zum Beispiel, der Typ

Datum:: day:nat1

month:nat1

year:nat

inv mk_Date (d, M, y) == Tag entspricht am 1. April 2001. In Anbetracht eines Datums ist der Ausdruck eine natürliche Zahl, die den Monat vertritt. Beschränkungen in den Tagen pro Monat und Schaltjahre konnten in den invariant, wenn gewünscht, vereinigt werden. Das Kombinieren von diesen:

mk_Date (1,4,2001).month = 4

Sammlungen: Sätze, Mappings und Sequences

Sammlungstyp-Mustergruppen von Werten. Sätze sind begrenzte nicht eingeordnete Sammlungen, in denen die Verdoppelung zwischen Werten unterdrückt wird. Folgen sind begrenzte bestellte Sammlungen (Listen), in denen Verdoppelung vorkommen kann und mappings begrenzte Ähnlichkeiten zwischen zwei Sätzen von Werten vertreten.

Der Satz-Typ-Konstrukteur (schriftlich, wo ein vorherbestimmter Typ ist) baut den Typ, der aus allen begrenzten Sätzen von vom Typ gezogenen Werten zusammengesetzt ist. Zum Beispiel, die Typ-Definition

UGroup = Satz von UserId

definiert einen aus allen begrenzten Sätzen von Werten zusammengesetzten Typ. Verschiedene Maschinenbediener werden auf Sätzen definiert, um ihre Vereinigung, Kreuzungen zu bauen, richtige und nichtstrenge Teilmenge-Beziehungen usw. bestimmend.

Der begrenzte Folge-Typ-Konstrukteur (schriftlich, wo ein vorherbestimmter Typ ist) baut den Typ, der aus allen begrenzten Listen von vom Typ gezogenen Werten zusammengesetzt ist. Zum Beispiel, die Typ-Definition

Schnur = seq der Rotforelle

Definiert einen aus allen begrenzten Reihen von Charakteren zusammengesetzten Typ. Verschiedene Maschinenbediener werden auf Folgen definiert, um Verkettung, Auswahl an Elementen und Subfolgen usw. zu bauen. Viele dieser Maschinenbediener sind im Sinn eingenommen, dass sie für bestimmte Anwendungen nicht definiert werden. Zum Beispiel ist das Auswählen des 5. Elements einer Folge, die nur drei Elemente enthält, unbestimmt.

Die Ordnung und Wiederholung von Sachen in einer Folge sind bedeutend, sind so dem nicht gleich, und sind dem nicht gleich.

Begrenzt kartografisch darzustellen, ist eine Ähnlichkeit zwischen zwei Sätzen, dem Gebiet und der Reihe mit den Bereichsindexieren-Elementen der Reihe. Es ist deshalb einer begrenzten Funktion ähnlich. Der kartografisch darstellende Typ-Konstrukteur in (schriftlichem) VDM-SL, wo und vorherbestimmte Typen sind) baut den Typ, der aus dem ganzen begrenzten mappings von Sätzen von Werten zu Sätzen von Werten zusammengesetzt ist. Zum Beispiel, die Typ-Definition

Geburtstage = stellen Schnur bis heute kartografisch dar

Definiert einen Typ, der Charakter-Schnuren dazu kartografisch darstellt. Wieder werden Maschinenbediener auf mappings definiert, um darin mit einem Inhaltsverzeichnis zu versehen, kartografisch darzustellen, sich mappings verschmelzend, überschreibend, sub-mappings herausziehend.

Strukturierung

Der Hauptunterschied zwischen dem VDM-SL und VDM ++ sind Notationen der Weg, auf den Strukturierung befasst wird. In VDM-SL gibt es eine herkömmliche Modulerweiterung, wohingegen VDM ++ einen traditionellen objektorientierten Strukturierungsmechanismus mit Klassen und Erbe hat.

Strukturierung in VDM-SL

Im ISO Standard für VDM-SL gibt es einen informativen Anhang, der verschiedene Strukturierungsgrundsätze enthält. Diese alle folgen traditionellen Informationsverheimlichungsgrundsätzen mit Modulen, und sie können als erklärt werden:

• Das Modul-Namengeben: Jedes Modul wird mit dem vom Namen des Moduls gefolgten Schlüsselwort syntaktisch angefangen. Am Ende eines Moduls wird das Schlüsselwort gefolgt wieder vom Namen des Moduls geschrieben.
• Das Importieren: Es ist möglich, Definitionen zu importieren, der von anderen Modulen exportiert worden ist. Das wird in einer Importabteilung getan, die mit dem Schlüsselwort begonnen und von einer Folge von Importen von verschiedenen Modulen gefolgt wird. Jeder dieser Modul-Importe wird mit dem Schlüsselwort angefangen, das vom Namen des Moduls und einer Modul-Unterschrift gefolgt ist. Die Modul-Unterschrift kann entweder einfach das Schlüsselwort sein, das den Import aller Definitionen anzeigt, die von diesem Modul exportiert sind, oder es kann eine Folge von Importunterschriften sein. Die Importunterschriften sind für Typen spezifisch, Werte, Funktionen und Operationen und jeder von diesen werden mit dem entsprechenden Schlüsselwort angefangen. Außerdem nennen diese Importunterschriften die Konstruktionen, dass es einen Wunsch gibt, Zugang dazu zu bekommen. Außerdem kann fakultative Typ-Information da sein, und schließlich ist es möglich, jede der Konstruktionen auf den Import umzubenennen. Für Typen muss man auch das Schlüsselwort wenn ein Wunsch verwenden, Zugang zur inneren Struktur eines besonderen Typs zu bekommen.
• Das Exportieren: Die Definitionen von einem Modul, dass ein Wunsch andere Module, um Zugang dazu zu haben, mit dem von einer Exportmodul-Unterschrift gefolgten Schlüsselwort exportiert wird. Die Exportmodul-Unterschrift kann entweder einfach aus dem Schlüsselwort oder als eine Folge von Exportunterschriften bestehen. Solche Exportunterschriften sind für Typen spezifisch, Werte, Funktionen und Operationen und jeder von diesen werden mit dem entsprechenden Schlüsselwort angefangen. Im Falle dass ein Wunsch, die innere Struktur eines Typs das Schlüsselwort zu exportieren, verwendet werden muss.
• Exotischere Eigenschaften: In früheren Versionen der VDM-SL Werkzeuge gab es auch Unterstützung für parametrisierte Module und instantiations solcher Module. Jedoch, diese Eigenschaften wurde aus VDMTools 2000 genommen, weil sie in Industrieanwendungen fast nie verwendet wurden und es eine bedeutende Zahl von Werkzeug-Herausforderungen mit diesen Eigenschaften gab.

Die Strukturierung in VDM ++

In VDM ++ Strukturierung werden mit Klassen und Mehrfachvererbung getan. Die Schlüsselkonzepte sind:

• Klasse: Jede Klasse wird mit dem vom Namen der Klasse gefolgten Schlüsselwort syntaktisch angefangen. Am Ende einer Klasse wird das Schlüsselwort gefolgt wieder vom Namen der Klasse geschrieben.
• Erbe: Im Falle dass eine Klasse Konstruktionen von anderen Klassen erbt, kann dem Klassennamen im Klassenkopfstück von den Schlüsselwörtern gefolgt werden, die von einer Komma-getrennten Liste von Namen von Superklassen gefolgt sind.
• Zugriffsmodifikatoren: Die Informationsverheimlichung in VDM ++ wird ebenso getan, weil im grössten Teil des Gegenstands Sprachen mit Zugriffsmodifikatoren orientiert hat. In VDM ++ sind Definitionen pro privaten Verzug, aber in von aller Definitionen ist es möglich, eines der Zugriffsmodifikator-Schlüsselwörter zu verwenden: und.

Das Modellieren der Funktionalität

Das funktionelle Modellieren

In VDM-SL werden Funktionen über die in einem Modell definierten Datentypen definiert. Die Unterstützung für die Abstraktion verlangt, dass es möglich sein sollte, das Ergebnis zu charakterisieren, das eine Funktion schätzen sollte, ohne sagen zu müssen, wie es geschätzt werden sollte. Der Hauptmechanismus, um das zu tun, ist die implizite Funktionsdefinition, in der, statt einer Formel, ein Ergebnis, ein logisches Prädikat über den Eingang und die Ergebnis-Variablen schätzend, eine Postbedingung genannt hat, gibt die Eigenschaften des Ergebnisses. Zum Beispiel könnte eine Funktion, für eine Quadratwurzel einer natürlichen Zahl zu berechnen, wie folgt definiert werden:

SQRT (x:nat) r:real

schlagen Sie r*r = x an

Hier definiert die Postbedingung keine Methode, für das Ergebnis zu berechnen, aber setzt fest, was, wie man annehmen kann, Eigenschaften davon halten. Bemerken Sie, dass das eine Funktion definiert, die eine gültige Quadratwurzel zurückgibt; es gibt keine Voraussetzung, dass es die positive oder negative Wurzel sein sollte. Die Spezifizierung wäre oben zum Beispiel durch eine Funktion zufrieden, die die negative Wurzel 4, aber die positive Wurzel aller anderen gültigen Eingänge zurückgegeben hat. Bemerken Sie, dass Funktionen in VDM-SL erforderlich sind, deterministisch zu sein, so dass eine Funktion, die die Beispiel-Spezifizierung oben befriedigt, immer dasselbe Ergebnis für denselben Eingang zurückgeben muss.

Eine mehr gezwungene Funktionsspezifizierung wird durch die Stärkung der Postbedingung erreicht. Zum Beispiel beschränkt die folgende Definition die Funktion, die positive Wurzel zurückzugeben.

SQRT (x:nat) r:real

schlagen Sie r*r = x und r> =0 an

Alle Funktionsspezifizierungen können durch Vorbedingungen eingeschränkt werden, die logische Prädikate über die Eingangsvariablen nur sind, und die Einschränkungen beschreiben, die, wie man annimmt, zufrieden sind, wenn die Funktion durchgeführt wird. Zum Beispiel könnte eine Quadratwurzel-Rechenfunktion, die nur an positiven reellen Zahlen arbeitet, wie folgt angegeben werden:

SQRTP (x:real) r:real

pre x> =0

schlagen Sie r*r = x und r> =0 an

Die Vorbedingung und Postbedingung bilden zusammen einen Vertrag dass, durch jedes Programm zufrieden zu sein, das behauptet, die Funktion durchzuführen. Die Vorbedingung registriert die Annahmen, unter denen die Funktion versichert, ein Ergebnis zurückzugeben, das die Postbedingung befriedigt. Wenn eine Funktion auf Eingängen genannt wird, die seine Vorbedingung nicht befriedigen, ist das Ergebnis unbestimmt (tatsächlich, Beendigung wird nicht sogar versichert).

VDM-SL unterstützt auch die Definition von rechtskräftigen Funktionen auf diese Art einer funktionellen Programmiersprache. In einer ausführlichen Funktionsdefinition wird das Ergebnis mittels eines Ausdrucks über die Eingänge definiert. Zum Beispiel könnte eine Funktion, die eine Liste der Quadrate einer Liste von Zahlen erzeugt, wie folgt definiert werden:

SqList: seq von nat-> seq nat

SqList (s) == wenn s = [] dann [] sonst [(hd s) ** 2] ^ SqList (tl s)

Diese rekursive Definition besteht aus einer Funktionsunterschrift, die die Typen des Eingangs und Ergebnisses und eines Funktionskörpers gibt. Eine implizite Definition derselben Funktion könnte die folgende Form annehmen:

SqListImp (s:seq nat) r:seq nat

schlagen Sie len r = len s und an

forall i im Satz inds s & r (i) = s (i) ** 2

Die ausführliche Definition ist in einem einfachen Sinn eine Durchführung der implizit angegebenen Funktion. Die Genauigkeit einer ausführlichen Funktionsdefinition in Bezug auf eine implizite Spezifizierung kann wie folgt definiert werden.

In Anbetracht einer impliziten Spezifizierung:

f (p:T_p) r:T_r

pre pre-f (p)

schlagen Sie post-f (p, r) an

und eine ausführliche Funktion:

f:T_p-> T_r

wir sagen, dass es die Spezifizierung iff befriedigt:

forall p im Satz T_p & pre-f (p) => f (p): T_r und post-f (p, f (p))

Also, "ist eine richtige Durchführung" sollte interpretiert werden, weil "die Spezifizierung befriedigt".

Das Staatsmodellieren

In VDM-SL haben Funktionen Nebenwirkungen wie das Ändern des Staates einer beharrlichen globalen Variable nicht. Das ist eine nützliche Fähigkeit in vielen Programmiersprachen, so besteht ein ähnliches Konzept; statt Funktionen werden Operationen verwendet, um Zustandsgrößen (AUCH BEKANNT ALS globals) zu ändern.

Zum Beispiel, wenn wir einen Staat haben, der aus einer einzelnen Variable besteht, konnten wir das in VDM-SL als definieren:

setzen Sie Register von fest

someStateRegister: nat

Ende

In VDM ++ würde das stattdessen als definiert:

Beispiel-Variablen

someStateRegister: nat

Eine Operation, um einen Wert in diese Variable zu laden, könnte als angegeben werden:

LAST (i:nat)

App. wr someStateRegister:nat

schlagen Sie someStateRegister = ich an

Die externals Klausel gibt an, auf welche Teile des Staates durch die Operation zugegriffen werden kann; Read-Only-Zugang anzeigend und Lesen/Schreiben-Zugang seiend.

Manchmal ist es wichtig, sich auf den Wert eines Staates zu beziehen, bevor es modifiziert wurde; zum Beispiel kann eine Operation, um einen Wert zur Variable hinzuzufügen, als angegeben werden:

TRAGEN SIE (i:nat) BEI

App. wr someStateRegister: nat

schlagen Sie someStateRegister = someStateRegister ~ + ich an

Wo das Symbol auf der Zustandsgröße in der Postbedingung den Wert der Zustandsgröße vor der Ausführung der Operation anzeigt.

Beispiele

Die Max-Funktion

Das ist ein Beispiel einer impliziten Funktionsdefinition.

Die Funktion gibt das Element von einer Reihe positiver ganzer Zahlen zurück:

max (s:set nat) r:nat

Pre-Karte s> 0

schlagen Sie r im Satz s und an

forall r' im Satz s & r' zu einer ausführlichen Definition:

multp (ich, j) ==

wenn i=0

dann 0

sonst, wenn das Sind sogar (ich)

dann 2*multp (i/2, j)

sonst j+multp (i-1, j)

Dann wird die Probeverpflichtung:

forall i, j: nat & multp (ich, j): nat und multp (ich, j) = i*j

Das kann richtig gezeigt werden durch:

1. Der Beweis, dass der recursion endet (verlangt das der Reihe nach Beweis, dass die Zahlen kleiner an jedem Schritt werden)
2. Mathematische Induktion

Warteschlange-Auszug-Datentyp

Das ist ein klassisches Beispiel, das den Gebrauch der impliziten Operationsspezifizierung in einem Zustandmodell einer wohl bekannten Datenstruktur illustriert. Die Warteschlange wird als eine aus Elementen eines Typs zusammengesetzte Folge modelliert. Die Darstellung ist ist immateriell und wird so als ein Scheintyp definiert.

Typen

Qelt = Jeton;

Warteschlange = seq Qelt;

der Staat TheQueue von

q: Warteschlange

Ende

Operationen

REIHEN SIE (e:Qelt) EIN

App. wr q:Queue

schlagen Sie q = q ~ ^ [e] an;

ENTFERNEN SIE e:Qelt

App. wr q:Queue

pre q

schlagen Sie q ~ = [e] ^q an;

IST - LEER r:bool

App.-Rd q:Queue

Posten r

Banksystembeispiel

Als ein sehr einfaches Beispiel eines VDM-SL Modells, denken Sie ein System, um Details des Kundenbankkontos aufrechtzuerhalten. Kunden werden durch Kundenzahlen (CustNum) modelliert, Rechnungen werden durch Kontonummern (AccNum) modelliert. Wie man hält, sind die Darstellungen von Kundenzahlen immateriell und werden so durch einen Scheintyp modelliert. Gleichgewichte und Überziehungen werden durch numerische Typen modelliert.

AccNum = Jeton;

CustNum = Jeton;

Gleichgewicht = interne Nummer;

Überziehung = nat;

AccData:: Eigentümer: CustNum

Gleichgewicht: Gleichgewicht

Staatsbank von

accountMap: Stellen Sie AccNum zu AccData kartografisch dar

overdraftMap: Stellen Sie CustNum zur Überziehung kartografisch dar

inv mk_Bank (accountMap, overdraftMap) == für alle im Satz rng accountMap & a.owner im Satz dom overdraftMap und

a.balance> =-overdraftMap (a.owner)

Mit Operationen:

NEWC teilt eine neue Kundenzahl zu:

Operationen

NEWC (od: Überziehung) r: CustNum

App. wr overdraftMap: Stellen Sie CustNum zur Überziehung kartografisch dar

schlagen Sie r nicht im Satz dom ~overdraftMap und overdraftMap = ~overdraftMap ++ {r |-> od} an;

NEWAC teilt eine neue Kontonummer zu und setzt das Gleichgewicht auf die Null:

NEWAC (cu: CustNum) r: AccNum

App. wr accountMap: Stellen Sie AccNum zu AccData kartografisch dar

Rd overdraftMap stellt CustNum zur Überziehung kartografisch dar

pre cu im Satz dom overdraftMap

schlagen Sie r nicht im Satz dom accountMap ~ und accountMap = accountMap ~ ++ {r |-> mk_AccData (cu, 0) }\an

ACINF gibt alle Gleichgewichte aller Rechnungen eines Kunden als eine Karte der Kontonummer zurück, um zu balancieren:

ACINF (cu: CustNum) r: Stellen Sie AccNum kartografisch dar, um Zu erwägen

App.-Rd accountMap: Stellen Sie AccNum zu AccData kartografisch dar

schlagen Sie r = {|-> accountMap (ein).balance | im Satz dom accountMap & accountMap (ein).owner = cu }\an

Werkzeug-Unterstützung

Mehrere verschiedene Werkzeuge unterstützen VDM:

• VDMTools sind die kommerziellen Hauptwerkzeuge für VDM und VDM ++, besessen, auf den Markt gebracht, aufrechterhalten und entwickelt durch CSK Systeme, auf frühere Versionen bauend, die von Danish Company IFAD entwickelt sind. Die Handbücher), und ein praktischer Tutorenkurs sind verfügbar. Alle Lizenzen sind kostenlos für die volle Version des Werkzeugs verfügbar. Die volle Version schließt automatische Codegeneration für Java und C ++, dynamische Verbindungsbibliothek und CORBA-Unterstützung ein.
• Ouvertüre ist eine gemeinschaftsbasierte offene Quellinitiative hat darauf gezielt, frei verfügbare Werkzeug-Unterstützung für VDM ++ oben auf der Eklipse-Plattform zur Verfügung zu stellen. Sein Ziel ist, ein Fachwerk für zwischendurchführbare Werkzeuge zu entwickeln, die für die Industrieanwendung, Forschung und Ausbildung nützlich sein werden.
• SpecBox: Von Adelard stellt Syntax-Überprüfung, etwas einfache semantische Überprüfung und Generation eines LATEX-Dateiermöglichens Spezifizierungen zur Verfügung, in der mathematischen Notation gedruckt zu werden. Dieses Werkzeug ist frei verfügbar, aber es wird weiter nicht aufrechterhalten.
• LATEX und LaTeX2e Makros sind verfügbar, um die Präsentation von VDM Modellen in der mathematischen Syntax der ISO Standardsprache zu unterstützen. Sie sind entwickelt worden und werden vom Nationalen Physischen Laboratorium im Vereinigten Königreich aufrechterhalten. [ftp://ftp.npl.co.uk/pub/latex/macros/vdm-sl/README ist Dokumentation] und [ftp://ftp.npl.co.uk/pub/latex/macros/vdm-sl/ Makros] online verfügbar.

Industrieerfahrung

VDM ist weit in einer Vielfalt von Anwendungsgebieten angewandt worden. Die wohl bekanntesten von diesen Anwendungen sind:

• Ada und KÜHLE Bearbeiter: Gültig gemachter Bearbeiter von Ada des ersten Europäers wurde durch das DDC-internationale Verwenden VDM entwickelt. Ebenfalls wurde die Semantik der KÄLTE und Modula-2 in ihren Standards mit VDM beschrieben.
• ConForm: Ein Experiment am britischen Weltraum, der sich die herkömmliche Entwicklung eines anvertrauten Tores mit einer Entwicklung mit VDM vergleicht.
• Staub-Experte: Ein Projekt, das von Adelard im Vereinigten Königreich für eine Sicherheit ausgeführt ist, hat Anwendung verbunden, die beschließt, dass die Sicherheit im Lay-Out von Industriewerken passend ist.
• Die Entwicklung von VDMTools: Die Meisten Bestandteile des VDMTools Werkzeug-Gefolges werden selbst mit VDM entwickelt. Diese Entwicklung ist an IFAD in Dänemark und CSK in Japan gemacht worden.
• TradeOne: Bestimmte Schlüsselbestandteile des Zurückbüro-Systems von TradeOne, das durch CSK Systeme für die japanische Börse entwickelt ist, wurden mit VDM entwickelt. Vergleichende Maße bestehen für die Entwickler-Produktivitäts- und Defekt-Dichte der VDM-entwickelten Bestandteile gegen den herkömmlich entwickelten Code.
• Netze von FeliCa haben die Entwicklung eines Betriebssystems für einen einheitlichen Stromkreis für Autotelefon-Anwendungen gemeldet.

Verbesserung

Der Gebrauch von VDM fängt mit einem sehr abstrakten Modell an und entwickelt das in eine Durchführung. Jeder Schritt schließt Daten Reification, dann Operationszergliederung ein.

Daten reification entwickeln die abstrakten Datentypen in konkretere Datenstrukturen, während Operationszergliederung die (abstrakten) impliziten Spezifizierungen von Operationen und Funktionen in Algorithmen entwickelt, die auf einer Computersprache der Wahl direkt durchgeführt werden können.

Daten reification

Daten reification (schrittweise Verfeinerung) schließen Entdeckung einer konkreteren Darstellung der abstrakten in einer Spezifizierung verwendeten Datentypen ein. Es kann mehrere Schritte geben, bevor eine Durchführung erreicht wird. Jeder Reification-Schritt für eine abstrakte Datendarstellung schließt das Vorschlagen einer neuen Darstellung ein. Um zu zeigen, dass die neue Darstellung genau ist, wird eine wiederbekommen Funktion definiert, der sich auf bezieht, d. h. Die Genauigkeit Daten reification hängt davon ab, Angemessenheit zu beweisen, d. h.

forall a:ABS_REP & besteht r:NEW_REP & = retr (r)

Seitdem sich die Datendarstellung geändert hat, ist es notwendig, die Operationen und Funktionen zu aktualisieren, so dass sie darauf funktionieren. Wie man zeigen sollte, bewahren die neuen Operationen und Funktionen jeden Datentyp invariants auf der neuen Darstellung. Um zu beweisen, dass die neuen Operationen und Funktionen diejenigen modellieren, die in der ursprünglichen Spezifizierung gefunden sind, ist es notwendig, zwei Probeverpflichtungen zu entladen:

• Bereichsregel:

forall r: NEW_REP & pre-OPA (retr (r)) => pre-OPR (r)

• Das Modellieren der Regel:

forall ~r, r:NEW_REP & pre-OPA (retr (~r)) und post-OPR (~r, r) => post-OPA (retr (~r), retr (r))

Beispiel-Daten reification

In einem Geschäftssicherheitssystem werden Arbeitern Ausweise gegeben; diese werden in Karte-Leser auf dem Zugang zu und Ausgang von der Fabrik gefüttert.

Operationen haben verlangt:

• initialisiert das System, nimmt an, dass die Fabrik leerer ist

• Aufzeichnungen, dass ein Arbeiter in die Fabrik eingeht; die Details der Arbeiter werden aus dem Ausweis gelesen)

• Aufzeichnungen, dass ein Arbeiter über die Fabrik herrscht

• Kontrollen, um zu sehen, ob ein angegebener Arbeiter in der Fabrik oder nicht ist

Formell würde das sein:

Typen

Person = Jeton;

Arbeiter = Satz der Person;

setzen Sie AWCCS von fest

pres: Arbeiter

Ende Operationen

INIT

App. wr pres: Arbeiter

schlagen Sie pres = {} an;

GEHEN SIE HEREIN (p: Person)

App. wr pres: Arbeiter

pre p nicht im Satz pres

schlagen Sie pres = pres ~ Vereinigung {p} an;

AUSGANG (p: Person)

App. wr pres: Arbeiter

pre p im Satz pres

schlagen Sie pres = pres ~\{p} an;

ISPRESENT (p: Person) r: bool

App.-Rd pres: Arbeiter

Posten r

Da die meisten Programmiersprachen ein mit einem Satz vergleichbares Konzept haben (häufig in der Form einer Reihe), ist der erste Schritt von der Spezifizierung, die Daten in Bezug auf eine Folge zu vertreten. Diese Folgen müssen Wiederholung nicht erlauben, weil wir nicht wollen, dass derselbe Arbeiter zweimal erscheint, so müssen wir einen invariant zum neuen Datentyp hinzufügen. In diesem Fall ist Einrichtung nicht wichtig, auch ist dasselbe als.

Die Wiener Entwicklungsmethode ist für musterbasierte Systeme wertvoll. Es ist nicht passend, wenn das System zeitgestützt wird. Für solche Fälle ist die Rechnung von kommunizierenden Systemen (CCS) nützlicher.

Siehe auch

• Formelle Methoden
• Formelle Spezifizierung
• Angelegenheitscode
• Prädikat-Logik
• Satzrechnung
• Z Spezifizierungssprache, die Hauptalternative zu VDM-SL (vergleicht)

Weiterführende Literatur

</ul>

• Fitzgerald, J.S. und Larsen, P.G. das Modellieren von Systemen: Praktische Werkzeuge und Techniken in der Softwaretechnik. Universität von Cambridge Presse, 1998 internationale Standardbuchnummer 0-521-62348-0 (die Bar Japanese Edition. Internationale 2003-Standardbuchnummer von Iwanami Shoten 4-00-005609-3).
• Fitzgerald, J.S. Larsen, P.G. Mukherjee, P., Plat, N. und Verhoef, M., Gültig gemachte Designs für Objektorientierte Systeme. Springer Verlag 2005. Internationale Standardbuchnummer 1-85233-881-4. Das Unterstützen der Website schließt http://www.vdmbook.com Beispiele und freie Werkzeug-Unterstützung ein.
• Jones, C.B. Systematische Softwareentwicklung mit VDM, Prentice Hall 1990. Internationale Standardbuchnummer 0-13-880733-7. Auch verfügbar online und kostenlos:

http://www.csr.ncl.ac.uk/vdm/ssdvdm.pdf.zip

• Bjørner, D. und Jones, C.B. Formal Specification and Software Development Prentice Hall International, 1982. Internationale Standardbuchnummer 0-13-880733-7
• J. Dawes, Der VDM-SL Bezugsführer, Bergmann 1991. Internationale Standardbuchnummer 0-273-03151-1
• Internationale Organisation für Standardisierung, Informationstechnologie — Programmiersprachen, ihre Umgebungen und Systemsoftwareschnittstellen — Wiener Entwicklungsmethode — Spezifizierungssprache — Teil 1: Grundsprache Internationaler Normaler ISO/IEC 13817-1, Dezember 1996.
• Jones, C.B. Softwareentwicklung: Eine Strenge Annäherung, Prentice Hall International, 1980. Internationale Standardbuchnummer 0-13-821884-6
• Jones, C.B. und Shaw, R.C. (Hrsg.). Fallstudien in der Systematischen Softwareentwicklung, Prentice Hall International, 1990. Internationale Standardbuchnummer 0-13-880733-7
• Bicarregui, J.C. Fitzgerald, J.S. Lindsay, P.A. Moore, R. und Ritchie, B., Beweis in VDM: ein Führer eines Praktikers. Springer Verlag Formal Approaches zur Computerwissenschaft und Informationstechnologie (FACIT), 1994. Internationale Standardbuchnummer 3 540 19813 X.

Links

• Information über VDM und VDM ++
• Vienna Definition Language (VDL)