A Model-based Standard for SDL

Andreas Prinz1, Markus Scheidgen2, and Merete S. Tveit1

1 Faculty of Engineering, Agder University CollegeGrooseveien 36, N-4876 Grimstad, Norway

andreas.prinz@hia.no, merete.s.tveit@hia.no2 Department of Computer Science, Humboldt Universitat zu Berlin

Unter den Linden 6, 10099 Berlin, Germanyscheidge@informatik.hu-berlin.de

Abstract. It is still the case that language descriptions have lots of se-mantic information captured using plain (English) text. These imprecisedescriptions are hardly usable for tools to generate language environ-ments out of the language standard. SDL has already managed to definesyntax and semantics in a quite formal way. Currently, this formality isusually connected to using grammars in one way or the other. On theother hand, meta-models have proven to be a good way of expressingcomplex facts and relations. Moreover, there are tools and technologiesavailable realising all language aspects based on completely formal andstill easily understandable descriptions. This paper reports about theexperiment to define a complete meta-model-based language definitionof (a subset of) SDL and to immediately have tool support for the lan-guage. This experiment includes the language aspects concrete syntaxrepresentation, static semantic constraints, and language behaviour. Itturns out that this is almost possible.

1 Introduction

Information technology is spreading more and more into all areas of daily life,leading to an increasing amount of information and applications of a very highcomplexity. Traditional methods of software production and data handling can-not cope with this increasing complexity. New ways of complexity handling usehigher levels of abstraction and describe systems with models. In particular,OMG puts forward their idea of a model-driven architecture (MDA) [11] whichfocuses on software development by means of high-level models. We will use theterm MDD (model driven development) in the following text to denote an ap-proach taking high-level descriptions for the generation of low-level results, e.g.executable code.

Because a computer language is software, that is usually coming in artifactslike standards and language tools, the language can be developed and maintainedin the same model-driven fashion. So the problem is to provide a human readablelanguage standard and tool support for languages based on models. There arebasically two ways to achieve this, either by writing a language standard andmanually building language tools or by having higher-level (meta-)tools that

2

allow to create descriptions which can be used as a language standard and inputfor automated generation of modelling tools. In any case it is necessary to have adescription of the language first. We will call such a description of the languagea meta-model.

There are varying levels of accuracy when it comes to describing meta-modelsand also a whole range of tools that support parts of this tool production byautomation. Of course, also meta-models are just a special kind of models andfor their handling we again need (meta-)modelling tools. This closes the circleand we can apply the same reasoning to the next level. So in all the levels wehave the need for powerful tools that are able to handle models of different kind.

The current SDL standard [7] including its formal semantics specification [6]already showed that most language aspects can be described formally withoutambiguities. In [2], Prinz et. al. showed that even aspects that are usually de-scribe informally, like language behaviour, can be described formally. Moreover,also tools can be created from such formal descriptions in an at least semi-automated way. In [3] we discussed the possibility to use meta-modelling as thebasis for integrating different languages and tools with each other. We alreadysuccessfully evaluated the possibilities for automated tools support based onmeta-models in the context of domain specific languages in [9, 13].

In this paper we use SDL to explain the use of different meta-modellinglanguages to realise descriptions for the different language aspects of SDL. Insection 2 we will introduce the different language aspects structure, constraints,behaviour, and representation, explain how they are related, and how they canbe described. The sections 3, 4, 5, 6 will present the approaches and technologiesthat we used to describe these aspects one by one. Each section contains partsof the SDL language as examples. In the concluding section 7, we discuss ourmethod and suggest further work.

2 Basics

In [8] meta-modelling is defined as: The construction of an object-oriented modelof the abstract syntax of a language. However, in our article we use the termmeta-model in a wider sense: A meta-model is a model that defines a languagecompletely including the concrete syntax, abstract syntax and semantics.

As a language description meta-models can have several aspects that we havealready identified in [9]. Figure 1 shows these aspects. Even though there is nocomplete agreement about what parts a language description consists of, these orsimilar parts can be identified in most contexts. The picture shows the followingparts.

Structural information for the meta-model including all the information aboutwhich concepts exist in the domain and how they are related. An example ofthis would be a MOF class diagram. In our understanding this part does justinclude very simple structural properties and not more advanced conceptsthat rely on the use of constraints.

3

Structure

Constraints

Repr

esen

tatio

n Behaviour

graphicaltextualmapping

execution

Fig. 1. Structure of a Meta-model.

Constraints giving additional information about the structure in that theyidentify the allowed structure according to additional logical constraints.This will include first-order logic constraints (e.g. written in OCL) as wellas multiplicity constraints. In classical compiler theory these are collectedunder the name of static semantics and in a meta-model context they arecalled well-formedness rules.

Representation description includes model serialization syntax and informa-tion about how the models are to be (re)presented to the user. The textualgrammars (concrete textual syntax) are well understood in terms of compilertheory. When it comes to graphical grammar (concrete visual syntax), thereis less agreement and also some open research topics.

Behaviour describes how the model is used. This item includes execution of themodel as well as mappings. By mapping we will understand a relation be-tween the model itself and another representation, e.g. in another language.A typical example would be a compiler from UML to Java, or mapping fromPIM to PSM. An execution is the real run of the model, which is of courseonly possible if the model is executable. A typical example here would be arun of a UML state diagram.

In the given picture, the structure is the central aspect and all the other partsrelate to the structure. This is quite clear for the constraints, which have tobe connected to the structural elements that they constrain. The representa-tion parts describe the representation of elements in the structure, whereas thebehaviour parts describe a behaviour for the elements define in structure.

3 Structure

The structure part of a language description defines an abstract data structurefor models, programs, or specifications written in that language. In model-drivendevelopment object-oriented models, like class diagrams, are used to model struc-tures. These type models use classes as refinable classifications of entities bymeans of shared characteristics, modelled with attributes. Associations are usedto classify the relations between entities. Associations are just a special kind ofclassifiers and actual links are a special kind of entities. Object-oriented type

4

models, in the form of class diagrams, are used in most meta-modelling archi-tectures.

We use two different meta-modelling platforms; one for displaying the lan-guage structure to human readers, and one for creating language tools. MOF 2.0[10] is used for presenting models and Ecore (the meta-modelling language ofEMF [1]) is used for the language tooling. Ecore is a simple language allowing toexpress structures with just a few basic concepts. It is similar to EMOF (essentialMOF). This is the set of basic features defined in MOF 2. In contrast, the CMOFmeta-modelling language (complete MOF, also defined in MOF 2) provides addi-tional concepts to model abstractions. For example, feature refinements allow torelate attributes or association ends in the context of classifier specialisation. InEcore the expressive power of these additional concepts has to be implementedmanually, for example with OCL-expressions. Because of its simplicity, Ecorehas the advantage of a clearer mapping to programming languages and moreextensive tool support.

SdlNamedElement

+name : LexicalName

SdlAgentType

+kind : SdlAgentKind

SdlClassifier

SdlParameter

+kind : SdlParameterKind

SdlNameSpace

SdlAgent

SdlVariable

SdlFeature

SdlSignal

{subsets member}+feature

0..*

{subsets feature}+variable

0..*

+type1

{subsets feature}+agent

0..*

{subsets variable,ordered}+parameter

0..*

+member0..*

+ownedAgentType

{subsets member}

0..*

Fig. 2. Classifier concepts in SDL.

In terms of languages, classes classify model elements based on the languageconcept that they instantiate. For example, all the agent types in all the SDLspecifications existing are instances of the agent type concept. The first samplemeta-model part in figure 2 describes the language concept agent type as ameta-model class. Attributes and associations are used to define the structuralcharacteristics of agent types: an agent type can contain other agent types, itcan contain type-based agents, it has parameters and variables. The examplealso shows how characteristics of more abstract language concepts can be reused.Agent types and signals for example, are just special classifiers having features asa general characteristics. Like SDL classifiers, they have variables as general butSDL-specific characteristics. Signals use parameters instead of variables, which

5

are among the features of SDL classifiers; agent types use agents, variables, andparameters as features where the parameters are a subset of the agent’s variables.

Using all the CMOF features to express abstractions, enabled us to composea meta-model for SDL from a predefined library of abstract language concepts.We re-used the UML infrastructure library, which was used to define the UML,accordingly to create the SDL meta-model. This approach makes sure that thetwo languages UML and SDL have a common base in their underlying languageinfrastructure.

SdlAgentType

+kind : SdlAgentKind

SdlAgent

SdlChannelEnd

SdlChannelPath

SdlChannel

SdlGate

SdlSignal

{subsets member}

+channel0..*

+agentType1

{subsets feature}

+agent0..*

{subsets member}+gate 0..*

+agentType

1

+source1+target1

+gate0..1

+channelEnd

0..*

+signal

0..*

+agent 0..1 +/opposite0..1

+path 1..2+channel1

+receive0..*+send0..*

Fig. 3. Concepts for communication structures in SDL.

Figures 3 show another part of the SDL meta-model. This meta-model partcovers the concepts of the sample specification in figure 3, which shows a blockdefinition as part of an example SDL specification (the entire SDL specificationcould be found in [14]). This block definition is given in SDL syntax and as anobject diagram, as an instance of the SDL meta-model.

4 Constraints

Structure models are designed to define valid graphs of objects and links, bydefining classes and associations. To complement these concepts of constructivemodelling, we used boolean expressions to constrain the possible instances of ameta-model.

To define such static semantic rules for SDL, we use the Object ConstraintLanguage (OCL) [12]. OCL is specifically designed as an expression language forobject-oriented structures. It allows to define expressions based on types definedin a meta-model. These expressions, defined at meta-level, can then be evaluated

6

Gext to Gout : SdlChannelPath

Gout to Gext : SdlChannelPath

WebCam : SdlAgentTypeCam : SdlAgentType

SR1 : SdlChannel

: SdlChannelEnd : SdlChannelEnd

: SdlChannelEnd : SdlChannelEnd

Gout : SdlGateGext : SdlGate

P : SdlAgent

ownedAgentType

agent

typegategate

gategate gate gatechannel

path

path

source source

target target

Fig. 4. Part of an example SDL specification and its model representation.

on models. OCL is a statically typed language. Each formula is defined in thecontext of an meta-model type. Based on this context type an expression can usethe features of the corresponding meta-element to navigate through models. OCLuses several predefined operators and functions to combine feature values intoa value for an OCL expression. Predefined functions and operators are derivedfrom first order predicate logic.

We will illustrate the use of OCL with a sample constraint as given in theSDL standard. The text in Z.100 [7] is as follows:

The contained Agent-definitions and Agent-type-definitions of a Processmust all have the Agent-kind process.

In the formal SDL semantics [6], this is formalised using first-order predicatelogic to define expressions over abstract syntax as follows:

∀d ∈ Agent-type-definition : (d.agentKind1 = process) ⇒

7

(d′ ∈ Agent-type-definition ∪Agent-defintion : d′.parentAS1 = d ⇒d′.agentKind1 = process)

In the meta-model, the same constraint is part of the context of SdlAgentTypeas follows:

context SdlAgentTypeinv: (self.agentKind = #PROCESS) implies

(self.ownedAgentType->union(self.agent.type)->forAll(agentKind = #PROCESS))

In our approach the meta-model reflects the SDL structures as defined withgrammars in the SDL standard. Therefore, we can use the same conditions fromthe SDL standard as a formal basis for corresponding OCL expressions. It isobvious that the two descriptions above match. The only difference is that inthe meta-model-based OCL we navigated along object structures, instead of setsand nodes obtained from the abstract syntax tree in the grammar-based SDLstandard.

Another sample constraint ensures compatibility of the two gates in bidirec-tional channels. It exemplifies the navigation through the more complex com-munication structures given in 3:

context SdlChannelinv: self.path->size = 2 implies

self.path->forAll(p1, p2 | p1 <> p2 implies(p1.source.gate = p2.target.gate andp1.target.gate = p2.source.gate))

Even though the name Object Constraint Language suggests that it canonly be used for constraints (boolean expressions), OCL allows arbitrary typedexpressions and is thus also suitable as a query language. This allows to de-fine derived and behavioural features in meta-models based on OCL, as long asthese features describe only query functionality, and therefore do not change themodel. In MOF meta-models these can be derived properties and query opera-tions. With derived properties and query operations, meta-modelling allows todefine utility functions on the static SDL models based on simple OCL expres-sions. These utilities can be used in the realisation of other language aspects,such as the language behaviour. The following example expression implementsthe association end attribute of SdlChannelEnd, which calculates the oppositechannel end of the context channel end (self ):

context SdlChannelEnd::opposite:SdlChannelEndbody: let otherChannelPath: SdlChannelPath =

self.channel.channel.path->select(c|c <> self.channel)->first() in

if channel.target = self then otherChannelPath.sourceelse otherChannelPath.target endif

8

A third way to use OCL is to automatically create constraints that realiseenhanced meta-modelling features. In section 3 we argued that the simple meta-modelling language Ecore can not be used to define the refinement of features.But those refinement expressions, provided by MOF 2, can be realised via OCLconstraints. For example, for each redefined property there has to be an OCLexpression that states that the redefined property always has the same values asthe redefining property.

5 Representation

A structure meta-model says something about the concepts in the language, andhow they are structurally related to each other, on a high level of abstraction.This structure is independent of its representation, which also implies that thereshould be clear boundaries between these two language features. The structureshould define the underlying vocabulary of the language, while the representationdescribes how the language is presented to the user.

5.1 Textual Representation

SDL is a language that has two syntax forms, a textual and a graphical. Althoughthe textual syntax is moved out of the standard into a separate attachment, itis still an important format for tools and information exchange.

The textual syntax is not directly related to the structure model of a lan-guage, which is more of an abstract syntax. For the first thing, the textualrepresentation contains information that is abstracted in the meta-model, suchas indentation, comments or keywords. If this was the only difference, we couldgenerate a unique concrete representation from a meta-model instance givensome formatting instructions. However, SDL does also allow several representa-tions for the same thing. In fact, most programming languages allow this kindof flexibility.

An example of this is illustrated in figure 5. We here have the structure onthe left-hand side and the textual representation on the right-hand side.

Fig. 5. Two representations of signal definition both corresponding to the same con-crete syntax

9

This way, the structure part of a meta-model acts as the common core ofall language elements, and the concrete representation is a additional part ofthe meta-model, which is mapped to the language meta-model. As figure 5 illus-trates, there might be several mappings to the same elements, as in the case ofthe signal definitions.

<signal definition>::=signal <signal definition item> { <comma> <signal definition item> }* <end> .<signal definition item> ::= <signal name> [<sort list>] .<sort list> ::= <left parenthesis> <sort> { <comma> <sort>}* <right parenthesis> .

This definition is mapped to the meta-model using the transformation

<signal definition>(items) ==>{ SignalDefinition(name=i.name, sorts=i.sorts) | with i in items }

Please note that this mapping is not bidirectional.

5.2 Identifier Resolution

A typical pattern in textual languages is the definition-use pattern. Some placean element is defined, an some other place or even several places the element isused. One may think of methods, variables, types or similar here. This situationis represented by an identifier in grammars, but by a direct link in a meta-modelaccording to the type property in the type of association. In order to capture thisfor grammars, we introduced a special construct to denote identifier definitionsand identifier uses making identifier resolution easy. This way identifiers onlylive in the textual representation and are almost useless for the meta-model.

Identifier resolution is formalised in the meta-model by a function resolvewhich does the resolution for an identifier given the complete SDL specification.

5.3 Graphical Representation

In the same way that a meta-model is used to specify the structural aspectsof a language, it could also be used to specify the graphical aspects. The ba-sic graphical concepts need to specify a syntax could be i.e. ellipse, line andrectangle with belonging properties. The graphical concepts are, like the struc-tural concepts, related to each other. While the relations between the conceptsin the structure describes how the language concepts are related to each otherin a abstract, structural way, the relations between the graphical concepts saysomething about how the concepts are related to each other graphically. Theserelations specify how the graphical concepts could be related to each other toform valid diagrams in that language.

The SDL block type diagram presented in the Structure section (ref. section3)was originally a part of a software prototype implemented in Cinderella SDL. Thelanguage concepts used in this prototype where then specified in GMF (Graph-ical Modeling Framework)[5] to build an SDL editor. GMF is a framework that

10

provides a platform for bulding graphical editors, and it acts as a bridging tech-nology between the GEF platform [4] and the EMF modelling platform. GMFconsists of two parts: the generative and the runtime part. The runtime partcould be seen as a a set of plug-ins that extends the already existing EMF andGEF functionality. The runtime part on the other hand is mainly covering theparts that make it possible for the user to define diagram editors using speciallydesigned EMF meta-models and to generate code based on this information.

When defining the graphical representation in GMF, all the graphical con-cepts that are in the language and their appearance are specified in the graphicaldefinition model. The tooling definition model makes it possible to give informa-tion about how the graphical concepts are represented in the editor toolbar andalso additional menu items, pop up menues etc. The graphical definition, thetooling definition and the structure definition (the .ecore file defined by EMF)are then bind correctly together by using the mapping model. The next step istransforming the mapping specification in to the generated model, which in turnis used to generate all the diagram code necessary to run the diagram editor.

Fig. 6. Meta-Meta-Model for Graphical Representation

11

In the following text, we will not focus on how GMF is used to specify thegraphical representation, but rather use our own approach to illustrate howmeta-models can be used to specify the language graphics. There are of coursesimilarities between the two approaches, but the most important difference isrelated to the higher abstraction level in our approach. While GMF descibes thewhole process for generating a diagram editor by meta-models, we will only focuson the part where the graphical concepts, their appearance and their relationsare specified.

To be able to specify some kind of representation by a meta-model, it isnecessary to have a meta-meta-model, The meta-meta-model defines the con-cepts that could be used to define the graphical concepts, in the same way thatMOF or Ecore defines which concepts and the relation between the conceptsthat are allowed to be used when defining a structure model (ref. section 3)Figure 6 presents how the meta-meta-model for graphical representation lookslike according to our approach. The top-level element is the graphical Specifi-cation that consists of a number of Diagram Elements. These diagram elementsare related to each other in one or another way. A Shape is a diagram element,and there exists two main categories of Shapes - Container Shape and Line. AContainer Shape is, as the name tells, a shape that can have other Diagram Ele-ments inside itself. A Container Shape could be a Rectangle, Ellipse, CustomisedShape or Text.

A Shape could have a number of Anchors, which is used to specify where aShape could be connected to another Shape. The anchor could be a point or anarea, and is specified based on the property Bounding in Shape.

Another important aspect of a graphical language, is the textual aspect.Most graphical languages do also include textual concepts, and how these textualconcepts are handled must also be included in the meta-meta-model. Inspired oftraditional grammar approaches for text handling, a Text element could be eithera Terminal or a Non-Terminal. A Terminal could be a Value which represents i.ethe name of an agent type, an attribute etc. A Terminal could also be a SpecialTextual Element. This includes both keywords (i.e. Signal, Use etc.) and specialsigns (i.e. ”;”, ”:” etc.) which is all predefined. An example of a Non Terminal isa Text Sequence. A Text Sequence is in turn a composition of a number of otherText Elements (both Terminals and Non-Terminals).

The meta-meta-model for graphical representation is at the same level as theMOF model (the meta-meta-model of MOF). In this way, the SDL graphicalrepresentation could be specified based on the graphical concepts presented infigure 6, and the SDL graphical meta-model will be an instance of the meta-meta-model for graphical representation. To illustrate how this will look like,a small excerpt of the SDL graphical meta-model is shown in figure 7. Thegraphical concepts specified in this meta-model are some of the concepts that arenecessary to model a Block Type diagram, and is corresponding to the conceptsin the structure meta-model in figure 3.

This graphical meta-model for SDL is then mapped to the meta-model thatspecifies the structure. Since there should be a clear separation between these

12

Fig. 7. SDL graphical meta-model for the concepts in figure 3

two language concepts, no direct references exist in the meta-models. The ideais that the different language aspects should not need to know about each other.The mapping is a simple horizontal mapping from the graphical representationto the structure starting with relating the top elements.

FrameSymbol ==>SDLAgentType

Then, the value from the SDLAgentKind in the heading of the diagram (fromthe graphics) will be mapped to the value of the AgentKind in the structure:

FrameSymbol.AgentTypeHeading.SDLAgentKind ==>SDLAgentType.kind

6 Behaviour

For an SDL standard only the execution semantics is relevant. Mappings areonly interesting for SDL compiler tools, but not necessary to define the SDLbehaviour.

To define the execution semantics we have to distinguish between two dif-ferent kinds of structure elements, as detailed in [?]. The first kind describesabstract syntax elements; the structure model of SDL consists of such elements.

13

The other kind of structure elements is needed to describe data that is needed atruntime. These runtime data includes things like variable assignments, processinstances, input buffers, etc. We therefore have to augment the regular struc-ture description for SDL with descriptions for this runtime data. The runtimeelements are usually related to corresponding syntax elements, e.g. an agent in-stance at runtime level represents an agent type defined at syntax level. In a way,when creating instances of syntax elements, the related runtime representationsare instantiated. This way the syntax elements function as factories produc-ing related runtime elements. Figure 8 shows the syntax and runtime structureneeded to describe the signal output action in SDL; syntax elements (white) arerelated to runtime elements (grey) by dashed arrows.

The SDL-2000 semantics is given in plain ASM [6], without using object-orientation. However, the current semantics already

used the two kinds of structural elements as identified above. There are run-time objects, in this case defined in ASM, which denote the objects existing atruntime, and there are syntax elements to be used at runtime, which in this caseare moved into the ASM domain by using a compilation function.

For the meta-model-based approach, we will skip the compilation functionand use the syntax elements directly. In this case, there will be an executionfunction attached to the corresponding syntax elements. This function is definedusing ASM. An example is seen in the figure, where output is a syntax elementwith an execution function. The execution function for the concrete SDL actionsignal output is given in ASM:

rule execute(o: Output, Self: SDLAgentInstance) =let values = [evaluate(a,Self) | a in arguments(o)] inSignalOutput(o, values, toArg(o))currentStatement(Self) := continueStatement(o)

rule SignalOutput(s,vSeq,toArg) =let invReference = (toArg memberof PId)?idToNodeAS1(s) notmemberofSignaldefinitionset(Interfacedefinition(toArg)) :false

inif invReference thenskip

elsechoose g in ingates(Self)with Applicable(s, toArg, g, undef) doextend SdlSignalInstance with si doSdlSignal(si) := sforall idx in Indices(vSeq) dovalue(parameterValue(si)[idx]):= vSeq[idx]

receiver(si) := toArgsender(si) := Self

14

SdlAction

+execute( context : SdlAgentInstance )

SdlAgentInstanceSet

...

SdlAgentType

...

Expression

+evaluate() : SdlDataValue...

SdlAgentInstance

...+run() : void

SdlSignal

SdlParameter

+kind : SdlParameterKind

SdlOutput

...

SdlSignalInstance

SdlAssignment

SdlVariableSlot SdlDataValue

SdlDataTypeSdlVariable

SdlAgent

SdlTimerSdlGate SdlSet

+argument0..*

+toArg

0..1

+classifier

{redefines classif ier}

+classif ier1

0..*

+receiver0..1

+sender1

+parameter0..1

+viaArg0..1

+value0..1

+type1

+inputQueue

0..*

+parameter0..*

+value0..*

+ow ningInstanceSet0..1

+type

Fig. 8. Runtime elements for state automatons.

Insert(si, now, g)endchoose

endif

As already stated in [?], the runtime elements have to have one context, whereasthe syntax elements need a runtime context and a syntax context. In the codeabove, Self denotes the runtime context, i.e. the actual agent instance. Thesyntax context (the signal output statement) is given by the first parameter inthe rule. In terms of object-orientation this first parameter resembles the thisparameter.

In a similar style, the behaviour for the runtime elements is given. One ex-ample here is a process instance:

rule Run(Self:SdlAgentInstance) = // AgentProgramif (agentMode1(Self) = initialisation) thenInitAgent

else if (agentMode1(Self) = execution) then

15

if ExecRightPresent(Self) thenExecAgent

elseGetExecRight

endifendif

In the object-oriented model, this function is associated to a runtime object oftype SDLAgentInstance, which is referred to in the ASM using the Self variable.

7 Conclusions

In this article, we presented an approach and the possible technologies to createa description of SDL that can be used as a human readable standard, as well as abasis for the automated generation of SDL reference tools. Thereby, we coveredthe language aspects structure, constraints, representation, and behaviour. Alltools necessary could be automatically generated: you can write an SDL speci-fication in a generated SDL editor, check this specification, and execute it. Wedid this for the basic part of SDL. This restricted SDL was extensive enough torealise the camera example with the generated tools.

The resulting meta-model for SDL has some limitations and there are issuesthat couldn’t be solved satisfactorily. The different language aspects, especiallyrepresentation, require extensions and modification of the language’s structuremodel. This creates the additional burden of aligning different similar modelswith each other. Examples for this are representations that often provide differentnotations for the same language concepts; behaviour operations and constraintsthat have to be put into the structure model, even though the structure model isindependent from these aspects. The presentation of the language description isanother problem, because meta-models used for tooling are cluttered with tech-nical information which is either not relevant for a standard or that a standardshould abstract from. Therefore, you need to describe more than necessary fora language standard to allow automatic tooling.

Compared to the SDL standard, our approach allows to utilize meta-model-based technologies that are more and more replacing grammar-based languagedevelopment tools. The object-oriented meta-models allow for better reuse ofabstract language concepts, and eventually lead to more coherent and compactlanguage description. The techniques used are mostly graphical and allow there-fore easier human comprehension. Meta-modelling in combination with propertooling, allows to display the language definition at different abstraction levelsby omitting details thereby enhancing human understanding.

All this leads to a language standard that is a model (or vice versa). Ofcourse, we can also have a printable document out of this model, but this isagain just another representation.

Future work will include further enhancements of language tools. Becausethose tools are generic tools parametrized through language descriptions, all

16

languages immediately profit from further enhancements in generic languagetooling. Another important point is support for evolving languages. A lan-guage, as software, yields requirements that may change over time and there-fore a language, its tools, and all the programs and specifications in a languagemay be subject to changes. Through the unification principle everything is amodel, also meta-models profit from agile modelling techniques. General tech-niques like model transformations, or meta-model specific techniques like meta-model/model co-adaptation might be used to either evolve a language or to tailora language to domain specific needs (profiling).

References

1. Frank Budinsky, David Steinberg, Ed Merks, Raymond Ellersick, and Timothy J.Grose. Eclipse Modeling Framework (The Eclipse Series). Addison-Wesley Profes-sional, August 2003.

2. Robert Eschbach, Uwe Glasser, Reinhard Gotzhein, Martin von Lowis, and An-dreas Prinz. Formal definition of SDL-2000: Compiling and running SDL specifi-cations as ASM models. In Abstract State Machines 2001: New Developments andApplications. J.UCS Special issue vol. 7, no. 11, 2001.

3. Joachim Fischer, Eckhardt Holz, Andreas Prinz, and Markus Scheidgen. Tool-based language development. Comput. Networks, 49(5):676–688, 2005.

4. Eclipse Graphical Editing Framework. See http://www.eclipse.org/gef.5. Eclipse Graphical Modeling Framework. See http://www.eclipse.org/gmf.6. ITU-T. SDL - ITU-T Specification and Description Language, Formal Semantics.

ITU-T Recommendation Z.100, Annex F, 1999.7. ITU-T. SDL - ITU-T Specification and Description Language (SDL-2000). ITU-T

Recommendation Z.100, 1999.8. Jack Greenfield and Keith Short, with contributions by Steve Cook and Stuart

Kent. Software Factories: Assembling Applications with Patterns, Frameworks,Models & Tools. John Wiley & Sons, September 2004.

9. Jan Pettersen Nytun, Andreas Prinz, and Merete Skjelten Tveit. Automatic gener-ation of modelling tools. In Arend Rensink and Jos Warmer, editors, ECMDA-FA,volume 4066 of Lecture Notes in Computer Science, pages 268–283. Springer, 2006.

10. OMG. Meta Object Facility (MOF) 2.0 Core Specification. Object ManagementGroup, October 2003. ptc/03-10-04.

11. OMG. Model Driven Architecture Guide, Version 1.0.1. Object ManagementGroup, June 2003. omg/03-06-01.

12. OMG. OCL 2.0 Specification. Object Management Group, June 2005. ptc/2005-06-06.

13. Markus Scheidgen and Joachim Fischer. Human comprehensible and machineprocessable specifications of operational semantics. In ECMDA-FA. Springer, 2007.LNCS.

14. Merete Skjelten Tveit. A cinderella-based prototype of a digital camera acontribution to the SDL05 design contest. Telektronikk 2.2006, 2006. See alsohttp://www.telenor.com/telektronikk/volumes/pdf/2.2006/Page 121-130.pdf.