3.3 Language to Specify Multi-Level Constructs
3.3.1 Language Proposal and Expressive Power
In the following, we present the formal specification of the Multi-Level Specification Language (MLSL) with 4 + 1 CF grammars using the EBNF notation [BBG+63].
The grammars (and thus the languages they describe) can be considered to be the sub-languages of MLSL, each with a separate purpose. The reason behind this sep-aration is prepsep-aration for practical application, where the sepsep-aration makes it easier to use the language. A fifth, common grammar is also presented, whose purpose is to provide re-usable production rules that the other grammars can use. The rules of the common grammar could be appended to the other grammars appropriately, but presenting it separately makes for a more focused presentation of MLSL. Thus, in the following, we present the grammars as follows: i) common grammar rules, ii) structure definition, iii) annotation definition, iv) semantic definition, and v) domain model definition.
Common Grammar Rules
The common grammar contains only common re-usable rules for the other gram-mars. Basic rules like operators, identifiers, numbers, or qualifiers are defined here.
For the sake of compactness and comprehensibility,all characters refers to the set of every valid character, while new line refers to the new line character.
harithmetic opi |= ” + ” | ”−” | ”∗” | ”/”
hlogical opi |= ” = ” | ”! = ” | ”<” | ”>” | ”<= ” | ”>= ” hintegeri |= [”−”] {hdigiti}
hrationali |= [”−”] {hdigiti}[”.” {hdigiti}]
hstringi |= 0”0 {hall charactersi −(0”0 new line)} 0”0 hidentifieri |= hletteri {hletteri | hdigiti | ” ”}
hqualifieri |= hidentifieri {”.”hidentifieri}
hletteri |= ”a” | ... | ”z” | ”A” | ... | ”Z”
hdigiti |= ”0” | ... | ”9”
The common grammar rules cannot be explicitly mapped to constructs in the formalism by themselves. However, it is worth noting that the static constants of the ASM (undef, true,f alse) and the literals referring to the universes (bool, number, string, base) can of course be expressed using the identif ier rule, but they are not explicitly differentiated in the grammar (but should be by the compiler of the language in practice).
Structure Definition
The sub-language for structure definition is responsible for defining structural en-tities and attributes (EAtt tuples) with EAttIsDomain = f alse. As it can be seen from the grammar, the syntax of the language is rather simple and contains only the basic concepts.
hstructmapi |= {hstructenti}
hstructenti |= hidentifieri” : ” hqualifieri”{” {hstructattri} ”}”
hstructattri |= hidentifieri” : ” hqualifieri[”[]”] ”; ”
From the derivation of structent rules, EAtt tuples with EAttIsDomain =f alse and EAttIsEntity = true - or in other words, structural entities - are created. The identif ier rule refers to the EAttN ame label of the tuple, while the qualif ier rule refers to the EAttM eta label. Note that the ”undef” static constant can of course be used if the value of EAttM eta label is undef. The EAttID label can be generated from theEAttN ame label. It is the responsibility of the compiler behind the language in practice to ensure that the identifiers are globally unique, namely, that ΦGlobalEA is enforced.
The derivation of every structattr rule leads to the creation of an EAtt tuple withEAttIsDomain =f alseandEAttIsEntity =f alse- or in other words, a structural attribute. This attribute is placed inside the EAttAttributes label of the containing structural entity (according to the grammar hierarchy). The EAttID andEAttN ame labels are filled in the same way as we have discussed for the structural entities.
The qualif ier rule refers to the EAttT ype label of the tuple, while the optional ”[]”
specifies the value of the EAttIsArray label. The EAttM eta label has to be filled out by the compiler. The most straight-forward approach is filling it out on a same-name basis.
To summarize, the label structure of EAtt in the structure definition language is mapped in the following way:
• EAttID: mapped by the identif ier rule in structent and structattr (respon-sibility of the compiler in practice)
• EAttN ame: mapped by the identif ier rule in structent and structattr
• EAttM eta: mapped by the qualif ier rule in structent, undef for structural attributes
• EAttAttributes: mapped by the structattr rules in structent
• EAttAnnotations: not mapped (see ΦDomainA)
• EAttAnnDef s: not mapped (mapped in the annotation definition sub-language)
• EAttT ype: mapped by the qualif ier rule in structattr
• EAttIsArray: mapped by ”[]” in structattr
• EAttV alue: not mapped (see ΦAttribute2)
• EAttIsEntity: always ”true” in structent, always ”false” in structattr
• EAttIsDomain: always ”false” in both structent and structattr
Annotation Definition
The sub-language for annotation definition is responsible for defining annotation def-initions. An annotation rule derivation results in the creation of anAnnDef tuple.
Every property of annotation definitions (mutability, optionality, range, targeted elements) can be specified.
hannotationsi |= {hannotationi}
hannotationi |= hmutabilityi hidentifieri [”?”]
”in” ”{” hrangei ”}” ”on”htargetsi hmutabilityi |= ”immutable” | ”mutable”
hrangei |= hintervali hliteralsi
hintervali |= hboundaryi ”..” hboundaryi hboundaryi |= hintegeri | ”∗”
hliteralsi |= hidentifieri {”,”hidentifieri}
htargetsi |= hqualifieri {”,” hqualifieri}
The mapping of the AnnDef label structure is rather simple and is as follows:
• AnnDefID: mapped by the identif ier rule inannotation
• AnnDefRange: mapped by the range rule (∞ is denoted by the ”*” symbol)
• AnnDefIsM utable: mapped by the mutability rule inannotation
• AnnDefT argeted: mapped by the targets rule in annotation; note that this should also automatically fill the value of the EAttAnnDef s label, in order to comply with ΦA8
• AnnDefIsOptional: its value is specified by the ”?” inannotation
Semantic Definition
The sub-language for semantic definition is responsible for defining the semantics of a construct (ΨX functions) in the form of validation rules. Of course, enforcing the rules defined by the ΦX functions earlier is the responsibility of the language and compiler. We have seen some of these functions implicitly mapped in the previous sub-languages (like ΦDomainA, ΦAttribute2, or ΦA8).
hvalidation rulesi |= {hvalidation rulei}
hvalidation rulei |= hif statementi | hsimple statementi
hif statementi |= ”if” ”(” hexpressioni ”)” ”{” hstatementi”}”
[helse statementi]
helse statementi |= ”else”hif statementi | ”{” hstatementi ”}”
hsimple statementi |= hexpressioni [hwhere clausei] ”; ” hwhere clausei |= ”where” (hexpressioni | hin clausei)
{”and” (hexpressioni | hin clausei)}
hin clausei |= hidentifieri ”in” hidentifieri hexpressioni |= hsimple expressioni |
”!” hexpressioni | haggregatei |
hexpressioni harithmetic opi hexpressioni | hexpressioni hlogical opi hexpressioni | hexpressioni (”and” | ”or”)hexpressioni | hqualifieri ”in”hclosurei |
hquantifieri |
”(” hexpressioni”)”
hsimple expressioni |= hqualifieri | hintegeri | ”true” | ”f alse” | ”null”
haggregatei |= (”count” | ”min” | ”max” | ”avg” | ”sum”)
”(” hqualifieri ”)”
hclosurei |= ”closure” ”(” hqualifieri”)” ”{” hstatementi ”}”
hquantifieri |= (”f orall” | ”exists”)hvardefi ” : ” hexpressioni [hwhere clausei]
hvardefi |= hidentifieri ”as” hidentifieri
From the derivation ofvalidation rule-s, ΨX functions are created. If statements are mapped to mathematical implications as usual. In the following, we examine how the special constructs in the formalism are mapped by the language. The where clause is responsible for mapping the select construct: the expression rule specifies the predicate and the in clause specifies the variable and collection. Of course, since both of these are optional, partially mapped select constructs (with an empty predicate or collection) are also possible. Theselect construct can also be mapped by the combination of aquantif ierand a (partially specified)where clause.
The closure rule - along with the related alternative on the right-hand side of the expression rule - is responsible for mapping the closure construct. The element is mapped by the qualif ier in the closure rule, while the expression is mapped by the statement in the closure rule. The count, min, etc. closures are mapped by the aggregaterule. Of course, theaggregaterule also has to be used in context (for example, in a f orall quantifier), since the rule itself only specifies the expression part of the constructs. We will see an example for this later.
The rest of the rules in the grammar correspond to their easily mapped mathe-matical counterparts. The quantif ier rule is mapped to the ∀and ∃ mathematical quantifiers respectively. The vardef rule serves as the variable in said quantifiers.
The expression rule also contains many other easily mapped concepts: negation, arithmetic and logical operators, logical conjunction (and) and disjunction (or), and grouping by parentheses.
To summarize, the concepts of the formalism in the semantic definition language are mapped in the following way:
• selectconstruct: mapped by thewhere clauseand optionally by aquantif ier
• closure construct: mapped by the closure rule and the relevant right-hand side alternative of the expression rule
• aggregate (count,min,max, and so on) constructs: mapped by theaggregate rule
• ∀and ∃quantifiers: mapped by the quantif ier rule
• mathematical implication: mapped by the if statementrule
• basic concepts (operators, negation, etc.) are mapped by theexpression rule Domain Model Definition
The sub-language for domain model definition is responsible for defining domain models (EAttandAnntuples). A domain model can only contain structural entities and attributes with EAttIsDomain =true. The mapping of tuples is very similar to that of the structure definition sub-language. The two main differences are i) the introduction of annotations (Anntuples) and ii) the definition of complex attributes (which only domain attributes can be, according to ΦAttribute4 and ΦAttribute5). The former is mapped by attributes (simpleattr) having the optional metric marker (”@”). The latter is mapped by the complexattr rule. Moreover, the EAttM eta label of attributes has to be assigned automatically by the compiler behind the language in practice. For example, this can be done on the basis of matching names (EAttN ame) in the meta and instance.
hdomaindefi |= {hdomainenti}
hdomainenti |= hidentifieri ” : ” hqualifieri ”{”{hdomainattri} ”}”
hdomainattri |= hsimpleattri | hcomplexattri hsimpleattri |= [”@”]hidentifieri ” = ” hvaluei ”; ”
hvaluei |= hqualifieri | hrationali | ”null” |
”true” | ”f alse” | hstringi | ”∗” hcomplexattri |= hidentifieri ”{”hdomainenti”}”
The label structure of EAttin the domain model definition language is mapped in the following way:
• EAttID: responsibility of the compiler in practice; mapped by theidentif ier rule indomainent, simpleattr, complexattr
• EAttN ame: mapped by the identif ier rule in domainent, simpleattr, and complexattr
• EAttM eta: mapped by thequalif ierrule indomainent; assigned automatically for attributes in practice
• EAttAttributes: mapped by the domainattr rules in domainent
• EAttAnnotations: mapped by simpleattr rules with the metric marker ”@”
• EAttAnnDef s: not mapped
• EAttT ype: mapped by thequalif ierrule instructattr(earlier, in the Structure Definition)
• EAttIsArray: mapped by ”[]” instructattr(earlier, in the Structure Definition)
• EAttV alue: mapped by the value rule in simpleattr
• EAttIsEntity: always ”true” in domainent, always ”false” indomainattr
• EAttIsDomain: always ”true” in both domainentand domainattr
The label structure ofAnn in the domain model definition language is mapped in the following way (when the metric marker ”@” is set in the language):
• AnnID: responsibility of the compiler in practice
• AnnDef inition: mapped by the identif ier rule in simpleattr
• AnnT arget: mapped by the identif ier rule in domainent
• AnnV alue: mapped by the value rule in simpleattr