Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Vienna Development Method
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==VDM features== The VDM-SL and VDM++ syntax and semantics are described at length in the VDMTools language manuals and in the available texts. The ISO Standard contains a formal definition of the language's semantics. In the remainder of this article, the ISO-defined interchange (ASCII) syntax is used. Some texts prefer a more concise [[Mathematical notation|mathematical syntax]]. A VDM-SL model is a system description given in terms of the functionality performed on data. It consists of a series of definitions of data types and functions or operations performed upon them. ===Basic types: numeric, character, token and quote types=== VDM-SL includes basic types modelling numbers and characters as follows: {| border="1" class="wikitable" |+ style="background:#ffdead;" | Basic Types |- | <code>bool</code> || [[Boolean data type|Booleans]] || {{mono|false, true}} |- | <code>nat</code> || [[natural number]]s (including zero) || {{mono|0, 1, 2, 3, 4, 5 ...}} |- | <code>nat1</code> || natural numbers (excluding zero) || {{mono|1, 2, 3, 4, 5, ...}} |- | <code>int</code> || [[integer]]s || {{mono|..., −3, −2, −1, 0, 1, 2, 3, ...}} |- | <code>rat</code> || [[rational number]]s || {{mono|a/b}}, where {{mono|a}} and {{mono|b}} are integers, {{mono|b}} is not {{mono|0}} |- | <code>real</code> || [[real number]]s || {{mono|...}} |- | <code>char</code> || characters || {{mono|A, B, C, ...}} |- | <code>token</code> || structureless tokens || {{mono|...}} |- | <code><A></code> || the quote type containing the value <code><A></code> || {{mono|...}} |} Data types are defined to represent the main data of the modelled system. Each type definition introduces a new type name and gives a representation in terms of the basic types or in terms of types already introduced. For example, a type modelling user identifiers for a log-in management system might be defined as follows: <syntaxhighlight lang="text"> types UserId = nat </syntaxhighlight> For manipulating values belonging to data types, operators are defined on the values. Thus, natural number addition, subtraction etc. are provided, as are Boolean operators such as equality and inequality. The language does not fix a maximum or minimum representable number or a precision for real numbers. Such constraints are defined where they are required in each model by means of data type invariants—Boolean expressions denoting conditions that must be respected by all elements of the defined type. For example, a requirement that user identifiers must be no greater than 9999 would be expressed as follows (where <code><=</code> is the "less than or equal to" Boolean operator on natural numbers): <syntaxhighlight lang="text"> UserId = nat inv uid == uid <= 9999 </syntaxhighlight> Since invariants can be arbitrarily complex logical expressions, and membership of a defined type is limited to only those values satisfying the invariant, type correctness in VDM-SL is not automatically decidable in all situations. The other basic types include char for characters. In some cases, the representation of a type is not relevant to the model's purpose and would only add complexity. In such cases, the members of the type may be represented as structureless tokens. Values of token types can only be compared for equality – no other operators are defined on them. Where specific named values are required, these are introduced as quote types. Each quote type consists of one named value of the same name as the type itself. Values of quote types (known as quote literals) may only be compared for equality. For example, in modelling a traffic signal controller, it may be convenient to define values to represent the colours of the traffic signal as quote types: <syntaxhighlight lang="bnf"> <Red>, <Amber>, <FlashingAmber>, <Green> </syntaxhighlight> ===Type constructors: union, product and composite types=== The basic types alone are of limited value. New, more structured data types are built using type constructors. {| border="1" class="wikitable" |+ style="background:#ffdead;" | Basic Type Constructors |- | <code><nowiki>T1 | T2 | ... | Tn</nowiki></code> || Union of types <code>T1,...,Tn</code> |- | <code>T1*T2*...*Tn</code> || Cartesian product of types <code>T1,...,Tn</code> |- | <code>T :: f1:T1 ... fn:Tn</code> || Composite (Record) type |} The most basic type constructor forms the union of two predefined types. The type <code>(A|B)</code> contains all elements of the type A and all of the type <code>B</code>. In the traffic signal controller example, the type modelling the colour of a traffic signal could be defined as follows: <syntaxhighlight lang="bnf"> SignalColour = <Red> | <Amber> | <FlashingAmber> | <Green> </syntaxhighlight> [[Enumerated type]]s in VDM-SL are defined as shown above as unions on quote types. Cartesian product types may also be defined in VDM-SL. The type <code>(A1*…*An)</code> is the type composed of all tuples of values, the first element of which is from the type <code>A1</code> and the second from the type <code>A2</code> and so on. The composite or record type is a Cartesian product with labels for the fields. The type <syntaxhighlight lang="text"> T :: f1:A1 f2:A2 ... fn:An </syntaxhighlight> is the Cartesian product with fields labelled <code>f1,…,fn</code>. An element of type <code>T</code> can be composed from its constituent parts by a constructor, written <code>mk_T</code>. Conversely, given an element of type <code>T</code>, the field names can be used to select the named component. For example, the type <syntaxhighlight lang="text"> Date :: day:nat1 month:nat1 year:nat inv mk_Date(d,m,y) == d<=31 and m<=12 </syntaxhighlight> models a simple date type. The value <code>mk_Date(1,4,2001)</code> corresponds to 1 April 2001. Given a date <code>d</code>, the expression <code>d.month</code> is a natural number representing the month. Restrictions on days per month and leap years could be incorporated into the invariant if desired. Combining these: <syntaxhighlight lang="text"> mk_Date(1,4,2001).month = 4 </syntaxhighlight> ===Collections=== Collection types model groups of values. Sets are finite unordered collections in which duplication between values is suppressed. Sequences are finite ordered collections (lists) in which duplication may occur and mappings represent finite correspondences between two sets of values. ==== Sets ==== The set type constructor (written <code>set of T</code> where <code>T</code> is a predefined type) constructs the type composed of all finite sets of values drawn from the type <code>T</code>. For example, the type definition <syntaxhighlight lang="rsl"> UGroup = set of UserId </syntaxhighlight> defines a type <code>UGroup</code> composed of all finite sets of <code>UserId</code> values. Various operators are defined on sets for constructing their union, intersections, determining proper and non-strict subset relationships etc. {| border="1" class="wikitable" |+ style="background:#ffdead;" |Main operators on sets (s, s1, s2 are sets) |- | <code>{a, b, c}</code> || Set enumeration: the set of elements <code>a</code>, <code>b</code> and <code>c</code> |- | <code><nowiki>{x | x:T & P(x)}</nowiki></code> || Set comprehension: the set of <code>x</code> from type <code>T</code> such that <code>P(x)</code> |- | <code>{i, ..., j}</code> || The set of integers in the range <code>i</code> to <code>j</code> |- | <code>e in set s</code> || <code>e</code> is an element of set <code>s</code> |- | <code>e not in set s</code> || <code>e</code> is not an element of set <code>s</code> |- | <code>s1 union s2</code> || Union of sets <code>s1</code> and <code>s2</code> |- | <code>s1 inter s2</code> || Intersection of sets <code>s1</code> and <code>s2</code> |- | <code>s1 \ s2</code> || Set difference of sets <code>s1</code> and <code>s2</code> |- | <code>dunion s</code> || Distributed union of set of sets <code>s</code> |- | <code>s1 psubset s2</code> || s1 is a (proper) subset of <code>s2</code> |- | <code>s1 subset s2</code> || s1 is a (weak) subset of <code>s2</code> |- | <code>card s</code> || The cardinality of set <code>s</code> |} ==== Sequences ==== The finite sequence type constructor (written <code>seq of T</code> where <code>T</code> is a predefined type) constructs the type composed of all finite lists of values drawn from the type <code>T</code>. For example, the type definition <syntaxhighlight lang="rsl"> String = seq of char </syntaxhighlight> Defines a type <code>String</code> composed of all finite strings of characters. Various operators are defined on sequences for constructing concatenation, selection of elements and subsequences etc. Many of these operators are partial in the sense that they are not defined for certain applications. For example, selecting the 5th element of a sequence that contains only three elements is undefined. The order and repetition of items in a sequence is significant, so <code>[a, b]</code> is not equal to <code>[b, a]</code>, and <code>[a]</code> is not equal to <code>[a, a]</code>. {| border="1" class="wikitable" |+ style="background:#ffdead;" |Main operators on sequences (s, s1,s2 are sequences) |- | <code>[a, b, c]</code> || Sequence enumeration: the sequence of elements <code>a</code>, <code>b</code> and <code>c</code> |- | <code><nowiki>[f(x) | x:T & P(x)]</nowiki></code> || Sequence comprehension: sequence of expressions <code>f(x)</code> for each <code>x</code> of (numeric) type <code>T</code> such that <code>P(x)</code> holds <br />(<code>x</code> values taken in numeric order) |- | <code>hd s</code> || The head (first element) of <code>s</code> |- | <code>tl s</code> || The tail (remaining sequence after head is removed) of <code>s</code> |- | <code>len s</code> || The length of <code>s</code> |- | <code>elems s</code> || The set of elements of <code>s</code> |- | <code>s(i)</code> || The <code>i</code><sup>th</sup> element of <code>s</code> |- | <code>inds s</code> || the set of indices for the sequence <code>s</code> |- | <code>s1^s2</code> || the sequence formed by concatenating sequences <code>s1</code> and <code>s2</code> |} ==== Maps ==== A finite mapping is a correspondence between two sets, the domain and range, with the domain indexing elements of the range. It is therefore similar to a finite function. The mapping type constructor in VDM-SL (written <code>map T1 to T2</code> where <code>T1</code> and <code>T2</code> are predefined types) constructs the type composed of all finite mappings from sets of <code>T1</code> values to sets of <code>T2</code> values. For example, the type definition <syntaxhighlight lang="rsl"> Birthdays = map String to Date </syntaxhighlight> Defines a type <code>Birthdays</code> which maps character strings to <code>Date</code>. Again, operators are defined on mappings for indexing into the mapping, merging mappings, overwriting extracting sub-mappings. {| border="1" class="wikitable" |+ style="background:#ffdead;" |Main operators on mappings |- | <code><nowiki>{a |-> r, b |-> s}</nowiki></code> || Mapping enumeration: <code>a</code> maps to <code>r</code>, <code>b</code> maps to <code>s</code> |- | <code><nowiki>{x |-> f(x) | x:T & P(x)}</nowiki></code> || Mapping comprehension: <code>x</code> maps to <code>f(x)</code> for all <code>x</code> for type <code>T</code> such that <code>P(x)</code> |- | <code>dom m</code> || The domain of <code>m</code> |- | <code>rng m</code> || The range of <code>m</code> |- | <code>m(x)</code> || <code>m</code> applied to <code>x</code> |- | <code>m1 munion m2</code> || Union of mappings <code>m1</code> and <code>m2</code> (<code>m1</code>, <code>m2</code> must be consistent where they overlap) |- | <code>m1 ++ m2</code> || <code>m1</code> overwritten by <code>m2</code> |} ===Structuring=== The main difference between the VDM-SL and VDM++ notations are the way in which structuring is dealt with. In VDM-SL there is a conventional modular extension whereas VDM++ has a traditional object-oriented structuring mechanism with classes and inheritance. ====Structuring in VDM-SL==== In the ISO standard for VDM-SL there is an informative annex that contains different structuring principles. These all follow traditional information hiding principles with modules and they can be explained as: * '''Module naming''': Each module is syntactically started with the keyword <code>module</code> followed by the name of the module. At the end of a module the keyword <code>end</code> is written followed again by the name of the module. * '''Importing''': It is possible to import definitions that has been exported from other modules. This is done in an ''imports section'' that is started off with the keyword <code>imports</code> and followed by a sequence of imports from different modules. Each of these module imports are started with the keyword <code>from</code> followed by the name of the module and a module signature. The ''module signature'' can either simply be the keyword <code>all</code> indicating the import of all definitions exported from that module, or it can be a sequence of import signatures. The import signatures are specific for types, values, functions and operations and each of these are started with the corresponding keyword. In addition these import signatures name the constructs that there is a desire to get access to. In addition optional type information can be present and finally it is possible to ''rename'' each of the constructs upon import. For types one needs also to use the keyword <code>struct</code> if one wish to get access to the ''internal structure'' of a particular type. * '''Exporting''': The definitions from a module that one wish other modules to have access to are exported using the keyword <code>exports</code> followed by an exports module signature. The ''exports module signature'' can either simply consist of the keyword <code>all</code> or as a sequence of export signatures. Such ''export signatures'' are specific for types, values, functions and operations and each of these are started with the corresponding keyword. In case one wish to export the internal structure of a type the keyword <code>struct</code> must be used. * '''More exotic features''': In earlier versions of the VDM-SL, tools there was also support for parameterized modules and instantiations of such modules. However, these features were taken out of VDMTools around 2000 because they were hardly ever used in industrial applications and there was a substantial number of tool challenges with these features. ====Structuring in VDM++==== In VDM++ structuring are done using classes and multiple inheritance. The key concepts are: * '''Class''': Each class is syntactically started with the keyword <code>class</code> followed by the name of the class. At the end of a class the keyword <code>end</code> is written followed again by the name of the class. * '''Inheritance''': In case a class inherits constructs from other classes the class name in the class heading can be followed by the keywords <code>is subclass of</code> followed by a comma-separated list of names of superclasses. * '''Access modifiers''': Information hiding in VDM++ is done in the same way as in most object oriented languages using access modifiers. In VDM++ definitions are per default private but in front of all definitions it is possible to use one of the access modifier keywords: <code>private</code>, <code>public</code> and <code>protected</code>.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)