¯ÆÝô
"Æ9Pg~¯¬
Ãô¯Úñ~ô
ôƬ¯ô6Mô d{Æ©ôM¯Ú À×9îggô×
Æ3ô©J¯Æ~ôaô3©x
½~ñ"Æ~ôÆ~¯PÆ×JP©ñPÔPÆ
ëP9~ôîÆ{{ô 0Æ{¯Æôô¯Æ{
a~ôG^^u
0Æ{¯Æôô¯Æ{P9ô~gP3ôש
ëÚñôg©gg©Æ3
£Æ~P×P{¯ô©
£Ú~P ô G^^u
"Æ9Pg~¯¬Ãô¯Úñ~x½³G^^u "Æ ©~ ¯~ ~9 Ê "Æ 9P g ~ ¯ ø 6 Úñ ô ô ¯Ú ñ ^
! " !
#$% && '(%)&& *+,!!!"#! -" &!$"! %$#&" "&&&""& "'&" $"&"())*$+ $""&, &"&&" &&- N%$" N%" $ N%$" %""$./"&& " &"" &"$ 0" %" ())*""'&&$# "& "&&& " $ %& $"&# $1 $ "&"&" $#&"& " $"$ 2" "#" $"" 3' $4& "& !5"#& &&" "& %&"1 $6"/())*& "&$"& $$" $"" $%"$$"""&&6" 3/"3" 47" &&&& " "&1"& " "" &'#7"5" %"&&&+ ,8#&1 $6"/3())*4$91: ;())*$<,///;) , ./6"1())*(="" $$& >"? &%& & $""&$ $""& ())*$"&&7"& & $"%!$" ##& $#$$" &""#"$ &- N.#" 3 4 N #3 4 N "23% @1&4 N3,9A,2"' 4 N3B"04 N."3. %%94 N1 C&."31 4 N/3D 4 N#38 4 N32 4 N314 NA#E#36 4 NCC"" 3,9A,F 2F 14 N3@ 14 N.3G# 4 N "32 4
N"63" H 1&4 ND"3" "4 NAD3G# 4 NID3 4 NJA3 4 N1 1 3! 4 ND1@5 %94 NA %3 14 N"D##%3 4 N6"% 3 06 4 N.@32"& E"4 N@3@5 %94 N/@3.% %94 N @31 $,& "&%94 N83 %94 NAC8 3" 4 N@I3@5 %94 4
%0$#&$&&K L !! !#38 4#&&3%$%94% J3% M.4/@3. %%94$"1 $6"/ $ $$$ %#"&&&"" &&#"&&"" :"#"!:./61())*&())* &&"$##""&& $&!())*- N&"$&./ N1A/,&"& $ NA,/6&"&A/ 1 $/" , &" &&"&' &&""7""$$" &"1 $6"/%$& "&"&" && "1 $6"/" $$$& 5
6
: , %% // 1 . / ) ! !
0 ! ) ! !
!
"#$"%&'
! () "#
!## *
!
$ +, ,# %
&
'
! *
&
! & (
-
"#$".& .
)" '
*" !!/ +
+ 01
,*+ 7
%
%) 2
+-
- )%-
$ &! 3
$ 4 ,# '
$ +, ,#
$ /"!! ,#
,# .
-" " %
"
"
)- & +
%& $
,!
D 9/ 6,1 %1
"#!## *
"&& ,/ ,# -
" ,+ '
$ +, ,# 8
DA: A % /0
&"&& ,/ ,#
! " # & -
" ,+
#!! $! %$! &'&' $ #!! &%&! %& 1
,+ !
% ,+
(()'* !+ ! !+ ()',&- &'# &" ()'+!! ()',(' .&' &"&' ,$ &'% %!
9
% 20 % &
)34&* 5,36 /2
5,36 /2
#&' #+ &' !&' !# &' /' &' &!,&'# )&' -5%1 &%& 36 (
$
$
+&#(!)(!&()( !# !+! ! !0!#! +! ()' ()', # ! !
+!& %& %45
*% 372 &
+!%!! +% ! (#### !! $ #) 1 1&" #$%
10
&0%
)- & %
(
"#$".& .
! &
/ + ! $$ +!! //2(#)'()' +&#(!1&(1 ! ()'+! +()'!,&&, ,+',)&&, !()' %70 --8 %!9') )
) + , ,# '
$ + , ,#
'# &# # ()' +!!# ##!$ % )& %
!! &
"#$".& .
! &
+ $! #+#! #!# # ,&&,+%#! #! #!!.# %#,&&, + !,+' 11
)&&& -:$-
+ #- 9
#- )
+# #- )
#-
+ 3 &(1&% 1! 4! !! ! )!! 0!! 5 ! -9) (
,&/ (
" ,&/
& ,&/
% ,&/ %
$ ,&/
,!! $% + !#! +! !%1 !3+ !&'1
12
% ;0 && <
3&& )# !
* !
! 1
!
-) ,&/ %
' ,&/
+&#(!)(!&()( +! !! !+ +%!% &()($) $ % , =+1%&& 6 9
+
6&') (6)('' ! %0! 6&'% %6)(' !% !/7" 876)(' # !% !6)( !87!/7 91+
13
14
A Language Description is Mor e than a Metamodel
Anneke Kleppe1, University Twente, Netherlands a.kleppe@utwente.nl Abstract. Within the context of (software) language engineering, language de- scriptions are considered first class citizens. One of the ways to describe languag- es is by means of a metamodel, which represents the abstract syntax of the language. Unfortunately, in this process many language engineers forget the fact that a language also needs a concrete syntax and a semantics. In this paper I argue that neither of these can be discarded from a language description. In a good lan- guage description the abstract syntax is the central element, which functions as pivot between concrete syntax and semantics. Furthermore, both concrete syntax and semantics should be described in a well-defined formalism. 1 Introduction In recent years attention for languages used in the development of software has grown. In [1] I have used the termsoftware languages to indicate either a modeling or program- ming language. I will use the same term in this paper to address the overall group of languages used in the development of software. No matter whether a software language is a modeling, programming, mark-up, or any other kind of language, it is created arti- ficially as opposed to natural languages, which evolution and growth can be called or- ganic. A consequence of the artificial nature of software languages is that its description is important and becomes an instrument for several tasks. First, the language description is used as input for the process in which the language designer creates a set of support- ing tools for the language user. Second, the language user is guided by the language de- scription in her understanding of a program/model written in that language. Language descriptions should therefore be created with utmost care. One of the ways to describe languages is by means of a metamodel, which represents the abstract syntax of the language. Unfortunately, when using metamodeling many language engineers forget the fact that a language also needs a concrete syntax and a semantics. Some language descriptions contain not even the slightest hint on either top- ic, for instance, the OMG’s Action Semantics [2] consists of an abstract syntax defini- tion only. Others contain only rudimentary information on these two topics, often written in natural language, the most well-known example is of course the UML [3]. 1.The author is employed in the GRASLAND project funded by the Dutch NWO (project number 612.063.408). 15 In this paper I describe what the components of a sound language description should be and some of the formalisms in which these elements can be expressed. I also show the mutual relationships between the elements of a language description and argue that the abstract syntax model is the central element, which acts as a pivot between the con- crete syntax description and the semantics descripttion. Section 2 of this paper sets the context for the discourse on language engineering. Section 3 explains the importance of concrete syntax, whereas Section 4 addresses the topic of semantics. Section 5 summarizes the elements of a solid language description and Section 6 concludes this paper. 2 The Context Before focusing on what a sound language description should look like, let us first set up the context of our discourse. When dealing with language engineering, obviously we need to have a definition of language. Fortunately, in the formal language theory there is an excellent, simple definition of what a language is (see for instance [4]). I adhere to this definition, although stated a little differently. Definition 1(Language) A language L is the set of all linguistic utterances of L. Obviously, we still need to define the concept of linguistic utterance. This term stems from natural language research where it represents any expression in a certain language, for instance a word, a sentence, or a conversation, see for instance [5, 6]. Some of the words that have been used in computer science with a similar meaning are: sentence, expression, statement, program, model. Unfortunately, like many other terms in our field, these terms have completely different meaning for different people. Therefore I use the term linguistic utterance when I want to be formal, and to avoid any bias I use the word mogram, which is short for model/program, in other cases. Now we are ready to focus on the language description, which I define as follows. Definition 2(Language Description) A language description of language L is the set of rules according to which the linguistic utterances of L are structured, optionally combined with a description of the intended meaning of the linguistic utterances. Although I have the opinion that a language description is not complete without a de- scription of the language’s semantics1, I know that there are people that disagree. To accommodate some freedom of mind, the above definition states that the semantics de- scription is optional. 1.What’s the use of speaking a syntactically perfect Russian sentence, when you do not know what it means? You might get slapped in the face, because of the abusive meaning of the sentence. Most humans prefer to speak sentences that both speaker and listener can understand, even if the sentences are syntactically flawed. 163 The Divide: Abstract and Concrete Syntax According to Definition 2 a sound language description minimally includes the syntac- tical rules according to which a mogram is structured. However, syntax can and should be divided into two: the concrete syntax and the abstract syntax, because the superficial structure of a mogram might be completely different from the underlying structure. In the words of the famous Noam Chomsky: “Surface structure does not necessarily pro- vide an accurate indication of the structure and relations that determine the meaning of a sentence” ([7] on page 93). With regard to the divide between concrete and abstract syntax we witness a peculiar bias, either towards the concrete or towards the abstract. For instance, when a language description takes the form of a (BNF) grammar, the concrete syntax takes the upper- hand. On the other hand, when a language description takes the form of a metamodel, the abstract syntax is overvalued. BNF as Formalism for Language Descriptions. When a language description is writ- ten in BNF, the focus of the language designer is biassed towards the concrete. A well- known fact is that a grammar contains superfluous information, like keywords and or- dering, that is not relevant to understand a particular mogram. Therefore, in the process of parsing a distinction is being made between a parse tree and an abstract syntax tree. Although the BNF rules specify the parse tree in a formal way, the abstract syntax tree is completely undefined. Most of the time it can be more or less directly derived from the parse tree. But certainly when an attributed grammar is being used, as is often the case in the field of visual language research (see for instance [8, 9]), the abstract syntax tree can differ greatly from the parse tree, as it is usually built in the form of a single attribute. More importantly, using the formalism of BNF, there is no adequate way to write an abstract syntax description. Metamodeling as Formalism for Language Descriptions. When a language descrip- tion is written in the form of a metamodel, the abstract syntax is the centre of focus. However, a metamodel does not contain information on how the concepts in the meta- model are to be represented to the language user. This is sometimes amended by intro- ducing an attributed form of metamodel in which each abstract concept holds an attribute that specifies its notation, for instance a graphical symbol. Many language en- gineering tools based on graph grammars (e.g. [10, 11, 12]) take this approach. Remem- bering the quote from Chomsky, immediately the flaw of this approach is clear: the concrete syntax is forced to take on the same structure as the abstract syntax. 3.1 Concrete and Abstract Syntax Models: Two Equally Valued Elements Although it is my opinion that the abstract syntax should play the central role in a lan- guage description, the concrete syntax must be treated with equal respect. It is crucial to language design and it deserves to be a separate element within the language descrip- tion. Furthermore, the language description should at least contain a mapping from con- crete to abstract syntax, and preferably also from abstract to concrete syntax. 17 Some argue that in modern (graphical) language environments there is no need to be specific about concrete syntax. There is no longer a need for a formally defined parser, and as one reviewer remarked: “At the low level information can be exchanged between different computers applications in a concrete-syntax free way using XML, and at the high level, humans can input linguistic utterances into a tool using forms (most tools provide pop up forms for directly manipulating the attributes associated with model el- ements). Thus, the only thing that remains is the need for renderings of models which are meaningful to humans.” However, because a language is a means of communica- tion, all language users need to agree on the XML schema for interchange as well as on the symbols to be used in rendering the mogram. Furthermore, both the XML schema and the set of symbols for rendering are definitions of (one of) the concrete syntax(es) of the language. If no agreement on concrete syntax would exist, anything could repre- sent anything, and language users would no longer understand each other. So how to proceed when creating a new language? Before answering this question, let’s have a look at some existing approaches. In [13, 14] for graphical (visual) and tex- tual languages respectively, the description of the concrete syntax and the description of the abstract syntax are separate entities belonging to one language description. Both syntax descriptions may be written in the same formalism, but it is also possible to use different formalisms. Fondement and Baar in [13] use the formalism of metamodeling for both. A separate metamodel representing concrete syntax elements is build and re- lated to the abstract syntax metamodel via a model transformation. xText [14] uses both metamodeling and BNF. From a existing BNF grammar that represents the concrete syntax, a metamodel is generated that represents the abstract syntax. My approach to textual languages (described in [15]) also uses both metamodeling and BNF. The concrete syntax is partially described by a metamodel, called parse model (PM), which is used to generate a BNF grammar, as depicted in Figure 1. Special here is that the PM is generated from the abstract syntax metamodel. Both generation steps take in user directives to produce the desired output. In all of these approaches there is a close link between the description of the concrete syntax and the description of the abstract syntax. In the process of creating a language description either one can be chosen as starting point, the other is developed together with the mapping to the first. My preference is to start with the abstract syntax in order not to introduce limitations posed by the concrete syntax in the description of the ab- stract syntax. A second reason for this preference is that in the case of a textual syntax the expressive power of BNF rules is less than that of a metamodel. A third reason is the fact that languages can have, and often have, multiple concrete syntaxes. Fig. 1 Separate concrete and abstract syntax definitions. 18
3.2 Expressive Power of BNF and Metamodels BNF rules are capable of describing trees, i.e. parse trees. At the same time a metamodel describes graphs, i.e. its instances are graphs. As trees are a subset of graphs, metamod- els in general are capable of describing a larger group of instances than sets of BNF rules. Therefore it is better to use a metamodel as starting point and create a BNF gram- mar from the metamodel, instead of using the more popular, and more easy, direction of creating a metamodel from a grammar. However, using the difference between non-composite and composite associations, a metamodel can be created in such a way that its instances are graphs in which a tree structure (the composite structure) is recognisable. In the work described in [15] this tree structure is used to generate the PM and ultimately the BNF rule set. 3.3 Multiple Syntaxes Languages can have, and often have, multiple concrete syntaxes. The mere fact that many languages have a separate interchange format (often XML-based), actually means that they have multiple concrete syntaxes, a ’normal’ syntax and an interchange syntax. At the same time there is a growing need for languages that have both a graphical and a textual syntax, as shown by tools like TogetherJ which uses UML as a graphical no- tation for Java. The UML itself is a good example of multi-syntax language. There is the well-known UML diagram notation [3], which is combined with the Human-reada- ble UML Textual Notation (HUTN) [16] and the interchange format called XMI [17]. A natural consequence of multiple concrete syntaxes is that concrete syntax can no longer be the focus of language design. There has to be a common representation of a linguistic utterance, which is independent of the concrete syntax in which it is entered by or shown to the language user. This common representation is the abstract syntax form of a linguistic utterance. The same form can be used to determine the meaning of the utterance, thus giving the abstract syntax description a pivotal role in the language description. 4 The Semantics The first thing we need to establish about a semantics description is that it is nothing more than a means to convey the understanding of a mogram from one person to anoth- er. Usually this is done not on a per mogram base, but on the base of the constructions in the language in which the mogram is expressed. This is more formally expressed in the following definition. Definition 3(Semantics Description) A description of the semantics of language L is means to communicate a subjective understanding of the linguistic utterances of L to another person or persons. A semantics desciption is included in a language description because the language de- signer wants to, or needs to, communicate your understanding of the language to other persons. An important consequence of this view is that computers are never part of the 19 audience of a semantics decription. Semantics descriptions of software languages are intended for human consumption, even when they describe the actions of a computer when executing a program. It is very important to explain the intended meaning of a lan- guage to other persons as clearly as possible. Similar to writing a paper or giving a pres- entation, the format of the semantics description should be adapted to its audience, the persons to whom the semantics description is addressed. 4.1 Different Types of Semantics There are at least four ways in which we can describe the semantics of a software lan- guage. (See [18] for a survey of semantic description frameworks.) These are: •Denotational, that is by constructing mathematical objects (called denotations or meanings) which represent the meaning of the program/model. •Operational, that is by describing how a valid mogram is interpreted as sequences of computational steps. The sequence of computational steps is often given in the form of a state transition system, which shows how the runtime system progresses from state to state. •Translational, that is by translating the mogram into another language that is well understood. •Pragmatic, that is by providing a tool that executes the program/model. This tool is often called a reference implementation. In my opinion, the best way to describe semantics to an audience of computer scientists is either translational or operational. If you can find a good target language, then the translational approach is probably the best. For instance, explaining the semantics of C# to a Java programmer is best done by translating the C# concepts to Java concepts, be- cause the two languages are so alike. When you lack a good target language, the oper- ational approach is second best. An example of the difference between the translational and operational approaches is a description of the meaning of the English phrase "to cut down a tree". You can either translate this phrase into some other language, like French: "réduire un arbre", or you can make a comic strip showing all the subsequent phases of cutting down a tree (a vid- eo would also do nicely). Each individual frame in the video, or picture in the comic strip, would be a state in the state transition system, hence the word snapshot that is of- ten used. 4.2 Operational Semantics using Graph Transformations The operational semantics of a software language describe what happens in a computer when a mogram of that language is executed. Execution means the processing of data. Therefore a semantics description should explain (1) the data being processed, (2) the processes handling the data, and (3) the relationship of these two with the possible lin- guistic utterances of the language. Together we call 1 and 2 the runtime system, (3) is called the semantic mapping. 20
The runtime system can be described using the formalism of metamodeling. For in- stance, in [19] we used a metamodel to describe what in compiler terminology is known as the heap, the data part of the runtime system, and the stack, the process part of the runtime system. The semantic mapping was in this case given by a set of graph trans- formation rules. Each rule can be applied only when a certain syntactic construction is present in the mogram and when at the same time a certain runtime state has been reached. For example, the rule describing assignment is executed only when the pro- gram counter has reached an assignment statement in the (abstract syntax graph of the) mogram and the value of the expression in the right hand side of the assignment is avail- able on the heap simultaneously. 5 The Components of a Language Description A sound language description contains the following elements: 1. an abstract syntax description; 2. one or more concrete syntax descriptions; 3. for each concrete syntax description: a mapping from concrete to abstract and preferably from abstract to concrete as well; 4. a description of the semantics in the form of a set of rules that govern an abstract machine that is able to execute any syntactically correct linguistic utterance of the language. The formalism used to express each of these elements can differ from the one to the oth- er, even within one language description. The use of combinations of formalisms to ex- press the various elements of a language description is a valid approach to language engineering. Choices for the formalism used to specify the abstract syntax are, for instance, met- amodeling and graph grammars. Some of the possibilities for the formalism for con- crete syntax description are BNF rules, and again metamodeling. The mappings between concrete and abstract syntax can be described as model transformations, using one of the various formalisms like QVT or ATL. For the semantics component the lan- guage designer has an even larger choice. My preference is to use graph transformation rules based on the concepts in the abstract syntax metamodel. 6 Conclusion A language description that only specifies abstract syntax is not enough. To rephrase the words of the old saying “one swallow does not make a summer”: one metamodel does not make a language. Language designers should take equally care to design con- crete syntax as well as semantics. The act of language design is one in which a carefull balance must be uphold be- tween the three main elements of a language description: abstract syntax, concrete syn- tax, and semantics. A software language should be build iteratively starting with parts of the abstract syntax, then adding concrete syntax and semantics to these parts. Thus 21 the result of each iteration will be a sound language description, in which every element takes its due place.
Refer ences
[1]Anneke Kleppe. Towards general purpose high level software languages. In Alan Hartman and David Kreische, editors, Model Driven Architecture – Foundations and Applications, volume 3748 of LNCS, Berlin Heidelberg, November 2005. Springer-Verlag. [2]OMG. OMG Unified Modeling Language Specification (Action Semantics). Technical Report ptc/02-01-09, OMG, 2002. [3]OMG. Unified modeling language: Superstructure. Technical Report formal/05- 07-04, OMG, 2005. [4]JohnE. Hopcroft and JeffreyD. Ullman. Introduction to Automata Theory, Lan- guages and Computation. Addison-Wesley, 1979. [5]Georgios Tserdanelis and Wai YiPeggy Wong, editors. The Language Files: Materials for an Introduction to Language and Linguistics. Ohio State University Press, 9th edition edition, April 2004. [6]Victoria Fromkin, Robert Rodman, and Nina Hyams, editors. An Introduction to Language. Heinle, 7th edition edition, August 2002. [7]Noam Chomsky. Language and Mind. Cambridge University Press, Cambridge, USA, 2006. [8]Da-Qian Zhang, Kang Zhang, and Jiannong Cao. A context-sensitive graph gram- mar formalism for the specification of visual languages. The Computer Journal, 44(3):186–200, 2001. [9]Gennaro Costagliola and Giuseppe Polese. Extended positional grammars. 2000 IEEE International Symposium on Visual Languages (VL’00), 00:103, 2000. [10]Roswitha Bardohl. GenGEd: Visual Definition of Visual Languages based on Algebraic graph Transformation. PhD thesis, TU Berlin, Berlin, Germany, 1999. [11]Mark Minas and G.Viehstaedt. Diagen: A generator for diagram editors providing direct manipulation and execution of diagrams. In V.Haarslev, editor, 11th IEEE International Symposium on Visual Languages, pages 203–210, Los Alamitos/ CA/USA, 1995. IEEE Computer Society Press. [12]Juan deLara and Hans Vangheluwe. Atom3: A tool for multi-formalism and meta-modelling. InFASE ’02: Proceedings of the 5th International Conference on Fundamental Approaches to Software Engineering, pages 174–188, London, UK, 2002. Springer-Verlag. [13]Frédéric Fondement and Thomas Baar. Making metamodels aware of concrete syntax. In Alan Hartman and David Kreische, editors, ECMDA-FA, volume 3748 ofLecture Notes in Computer Science, pages 190–204. Springer, 2005. [14]xText. http://www.eclipse.org/gmt/oaw/doc/4.1/r80_xtextReference.pdf, 2007. [15]Anneke Kleppe. Towards the generation of a text-based IDE from a language metamodel. In DavidH. Akehurst, Régis Vogel, and RichardF. Paige, editors, Proceedings of the third European Conference on MDA, 2007, volume 4530 of LNCS, pages 114–129, Berlin Heidelberg, June 2007. Springer-Verlag. 22[16]OMG. Human-usable textual notation (HUTN) specification. Technical Report formal/04-08-01, OMG, 2004. [17]OMG. MOF 2.0/XMI mapping specification, v2.1. Technical Report formal/05- 09-01, OMG, 2005. [18]Yingzhou Zhang and Baowen Xu. A survey of semantic description frameworks for programming languages. SIGPLAN Notices, 39(3):14–30, 2004. [19]Harmen Kastenberg, Anneke Kleppe, and Arend Rensink. Defining object-ori- ented execution semantics using graph transformations. In R.Gorrieri and H.Wehrheim, editors, FMOODS 2006, volume 4037 of LNCS, pages 186–201, Berlin Heidelberg, June 2006. Springer-Verlag. 23
Making Mode ling L anguages F it fo r Mo d el-Dri v en D ev elopment
ThomasKühne DarmstadtUniversityofTechnology,Germany kuehne@informatik.tu-darmstadt.de Abstract.Inthispositionstatement,Iarguethatmodelinglanguagesthataspire tobeusedinamodel-drivendevelopmentcontextmustfulfillmorerequirements thantraditionalnotationsthathavebeenprimarilyusedforsolutionsketching.I enumeratesomeoftheserequirements,evaluatetowhatextenttheyareaddressed bytheUML,andsuggesthowtheUMLcouldbeenhancedinordertobecomea modelinglanguagethatadequatelysupportsmodel-drivendevelopment. 1Introduction Model-drivenDevelopment(MDD)embodiestheideaofraisingthelevelofabstrac- tionofartifactsintendedtoinstructcomputerhardware.Insteadofrequiringdevelopers tothinkandspecifyattheprogramminglanguagelevel—e.g.,thelevelofabstraction affordedbyJava—theyshouldbeallowedtousemoreabstractwaysofspecifyinga solution.Conceptually,thenotionofmodel-drivendevelopmentisthereforejustacon- tinuationoftheageoldcomputersciencetrendtoincreasetheproductivityofprogram- mersbyofferingthemanincreasingnumberofwaystoraisethelevelofabstraction oftheirprograms.Thefactthatthenextgenerationofprogramminglanguageswill, ingeneral,haveavisualnotationandhavetraditionallybeencalled“modelinglan- guages”,arejustcoincidentaldetailsofthisparticularstepinprogramminglanguage evolution.Likewise,yieldingadvantagesregarding“platformindependence”—afea- tureusedinmarketingMDD—isjustaparticularincarnationoftheageoldideaofpre- ferringproblem-orientedspecifications(addressingthequestionWhat?)oversolution- orientedrealizations(addressingthequestionHow?). Obviously,amodelinglanguagethathithertohasbeensuccessfullyusedforsketch- ingsolutionswillnotautomaticallybesuitabletosupportMDD.Enablingdevelopers tocreatehigh-levelartifacts,thatarefreefromanysolution-orienteddetailsandcan automaticallybecompiledintomachinecode(typicallyinvolvingseveralintermediate steps),requiresmorethanwhattypicalmodelinglanguages,suchastheUML[15], currentlyhavetooffer. 2MDDLanguageRequirements Inthefollowing,Iwillnotattempttopresentanexhaustivelistofrequirementsforan MDDlanguage.Inparticular,Iwillnotfurtherexamineanumberofrequirementsthat canbeconsideredtobebasic.Amongsuchbasicrequirementsforalanguageare: 24II –awaytoascertainwhethersentencesinthelanguagearewell-formed. –thepossibilitytoassignprecisemeaningtowell-formedsentencesofthelanguage. –thepropertythatvariouspartialspecifications(e.g.,diagrams)willmatchuptoa coherentandcompletewhole(e.g.,amodel). –somemeanstoconstructivelydescribestructure/behaviorforthosepartsofaspeci- ficationwheredeclarativedescriptionscannotorshouldnotbeautomaticallyturned intoconstructivedescriptions. –adherencetobasicrulesofsemioticsregardingitsconcretenotation. Inshort,amodelinglanguageaspiringtosupportMDDmustfirstfulfillthebasicre- quirementsofaprogramminglanguage. 2.1StandardsvsDomain-SpecificApproaches NotethatintheaboveIdonotrequirealanguagetohaveastandardsemantics.Infact, ImaintainthattheUML’spropertyofbeingopentointerpretationinsomeaspects—in theabsenceofacompleteformalspecificationandwiththedeliberateintroductionof so-called“semanticvariationpoints”—hasbeenafeatureoftheUMLnotabug,sig- nificantlyaidingitswidespreadadoption.Thelessrestrictivethemeaningofanotation, themoreuserscanchoosetheirownfavoriteinterpretationforit. TheincreasingpopularityofDSL/DSMapproachesalsotestifiestotheutilityof usingalanguagewithconceptsandsemanticstailoredtoaparticulardomain.However, whilethechoiceovertailoredconceptsandconcretenotationiscertainlyasuccess factorforDSLs,theabilitytodefineindividualwell-formednessrulesand/orsemantics forotherwiseidenticalnotation,issurelyalsoofgreatimportance.Ingeneral,domain- specificityisattractiveforindividualdevelopersorsmallgroupssincetheycanthen workwithatoolthatisoptimallytailoredtotheirproblemdomain.Thelargerthe groupbecomes,e.g.,thesizeofabigorganization,themoreitwillstrugglewithan inherentdisadvantageofthisapproach:Theartifacts,expressedinahighlydomain- specificnotationandusinghighlydomain-specificconcepts,willbenexttounreadable toanyonewhohasnotinvestedtheeffortoflearningthedomain-specificlanguage. Hence,thelargeracommunitybecomes—certainlyatthelevelofmulti-lateralinter- organizationcommunication—themorevalueitwillobtainfromlanguageswithastan- dardizednotationandsemantics.Unfortunately,itisnotpossibletohaveyourcake(an optimallanguage)andeatittoo(beuniversallyunderstood).Section3,however,de- scribesanapproachthatbalancestheforcesofthisspecificitydilemma. Inthefollowing,Iwilldiscussoneissueaddressingtheorganizationofspecifica- tions,andtwoissuesaddressingtheabsenceofanytracesofsolution-orientedinforma- tioninproblem-orientedartifacts.Althoughseeminglyverydifferent,allthreeissues haveincommonthattheyaimatprovidingdeveloperswithhigherlevelsofabstraction. 2.2RaisingtheLevelofAbstraction First,assoonasmodelsarenolongersketchesthatintentionallyleaveoutalotofre- quired(asopposedtoderivableorsupplementary)detail,theywillbecomelargerand 25 III lessmanageablethantheyusedtobe.Thisimpliesaneedforbettermeansforstructur- ingandhandlinglargemodels,i.e.,somewaytosolvethespecificationdecomposition problem.
patter na rti fa cts
ProductType name:String
ProductType name:String MonitorModel size:String ct1:ComputerModel name="PCstandard" processor="3.1Ghz"
c1:Computer
mt1:MonitorModel name="Flat19" size=19
m1:Monitor
Product ComputerMonitor isOfTypeisOfType isOfTypeisOfType
model instances
model types domaintypesdomaininstances
ItemDescription Pattern
ed
risc
tiop
n item
isOfTypeisOfType
do ma in met atyp es
ComputerModel processor:String 01
2 Fig.1.RepresentingTypesWithObjects Second,inordertobesolution-independentandhenceimmunetochangesinthe choiceofrealizationstrategies,modelsmustavoidanypollutingtracesofsolution- orientedchoices.However,suchpollutioneasilyoccursifamodelisannotatedwith informationintendedtoguidetransformations.So-called“marks”[14],ifchosentore- latetosolution-orientedinformation,e.g.,indicatingthatanameshouldbetransformed intoastringwith40characters,contaminatetheproblem-orientedmodelwithsolution- orientedinformationandconsequentlymakeitlessimmunetofuturechangesrelated tosolutiontechnology.Thisproblemappearsinitsworstform,ifmarksareimple- 26
IV mentedwithmodelinglanguagefeaturesthateffectivelyconstituteinseparablepartsof amodel,suchasstereotypesortaggedvalues.Itstillexiststhough,evenifonemanages to“overlay”marksontothemodellikeatransparencysheet[14],sincethecorrespon- dencebetweenmodelelementsandtheirmarksmustbeestablishedsomehowandcan createamaintenanceissueincasethemodelorthesolutiontechnologyarechanged.In summary,wearefacingapollutingtransformationphenomenon. Third,anothersourceformodelpollutionarelimitationsofsolutiontechnologies whicharesilentlycarriedovertothelevelofproblemspecificationswithouteverbe- ingquestioned.Onesuchlimitationisthetraditionalrestrictionoftheobject-oriented paradigmtoonlytwologicallevels,featuringtypesandinstances.Figure1showsthe designofacomputerhardwareproducthierarchy,whichisinspiredbyanexamplethat Engelsetal.usedtoillustratethestateoftheartofmodelingwiththeUML[10]. ThedesignofFig.1usesthe“ItemDescription”pattern[8],alsoknownas“Type Object”[12],anddocumentscommondeveloperspractice,supportingadynamictype levelwithanordinaryobject-orientedprogramminglanguage.Sincetypessuchas“ct1” canbeaddedandremoveddynamically,theymustberepresentedasobjectsandonly playtheroleoftypesforotherobjects.Thisleadstoanumberofproblems[5]wich aretoonumeroustobelistedhere,butnoticethatalotofwhatwouldhavebeenpro- videdbylanguagesupport,suchasobjectcreationwithindividualconstructors,dy- namicdispatch,etc.mustnowbeemulated.Alsonotethatwhiledomaininstancesand typesarerepresentedwithobjects,thedomainmetatypesarerepresentedasclasses (seethecircularlabels0–2).Theadditionalmachineryrequiredandthemuddledup useofUML-supportedinstantiation(between“ct1”and“ComputerModel”)anduser- modeledinstantiation(between“c1”and“ct1”)isaninevitableconsequenceofusinga two-levelparadigmtoaccommodateathree-levelproblem.Thereisnothingtobesaid againstthemodelofFig.1ifitismeanttomodelthesolution,however,whenregarded asaproblem-orientedspecification,ithastoberegardedasfeaturingaccidentalcom- plexity[6].Section3describesanotherversionofthemodelwhichdoesnotfeaturethis additionalaccidentalcomplexity,causedbyamodelingparadigmthatsuffersfroma two-levellimitation. 3UMLShortcomingsandSomeSolutions Thespecificitydilemmamentionedinsubsection2.1canbeaddressedbyusingdomain- customizedlanguages[4],thatareconstructedaccordingtothefollowingmaxime:Start withastandardizedlanguageandthenincrementallymakeitspecifictoyourproblem domainasmuchasnecessary,butnomorespecific.Thisstrategyprovidesdevelopers withanoptimallyadaptedlanguagewhilepreservingthemaximumamountofuniversal communicationpossible.TheUMLhashadasimilaranswertothespecificitydilemma withitsideaofa“familyoflanguages”[9]foralongtime,butnevermanagedtosupport itwellthroughitsprofilemechanism,whichislimitedbytheratherweakstereotype conceptitisbasedon. IftheUMLwantstorepresentthebestofbothworlds(modelingstandard&domain- specificity)itneedstobecomeasmalllanguageintendedforbuildinglargemodeling libraries,i.e.,becomethe“UnifiedModelingLibrary”[3,2],muchinthesenseofthe 27 V approachdescribedbyGriswoldetal.forprogramminglanguages[11].Thepackage combinationoperatorsoftheMOF[16]havehithertoonlybeenusedforincrementally specifyingtheUMLbutcouldalsobethebasisforanumberofsystematiccustomiza- tionoperators. Thespecificationdecompositionproblemcanbeaddressedwithtwopowerfultech- niques:refinementandhierarchicalstructuring.Theformercanbeusedtoprovidesim- plifiedversionsofotherwisecomplexartifacts,e.g,asinarchitecturestratification[1], whereasthelattercanbeusedtoorganizeanartifactbasedontheprincipleofaggrega- tionasexemplifiedbytheHOODmethod[17].Thesetechniquesdonotexcludeeach otherbutcanbeeffectivelyusedinconjunction[7]. TheUMLhasaddedsomesupportforhierarchicaldecompositioninitsrecent2.0 version[15]butstilloffersonlymeagersupportforrefinement.Itneedstoimprovein bothareasinordertomakefull-sizeMDDmodelsmanageable. Thepollutingtransformationphenomenoncanbeaddressedbyprovidingguidance totransformations—e.g.,categorizingmodelelementsaccordingtothewaytheyneed tobetransformed—inamannerthatonlyreferstoproblem-orientedpropertiesofel- ements.Insteadofdecoratingelementswithpiecesofinformationlike“EJBSession Bean”and“EJBEntityBean”oneshouldusecategoriessuchas“Transaction”and “Item”.Eitherthetransformationthendirectlyknowsabouthowtomapsuchcategories oritmayconsultadictionarywhichprovidesamappingfromproblem-orientedto solution-orientedcategories.Notethatthiswaythemappingisstillsensitivetochanges regardingthetransformationofaclassofelements(suchasall“items”)but,incontrast toamarkingapproach,isimmuneatthelevelofindividualmodelelements. Thetwo-levellimitationcaneasilybeliftedbyallowingdeveloperstouseasmany logicalmodelinglevelsastheywish.Figure2showsacorrespondingversionofthe modelinFig.1.NotethatinFig.2,themodelinglevelsforinstances,types,and metatypesalignwiththedomaininstances,types,andmetatypesrespectively.Con- sequently,theinstantiationchainformedbytheelementswiththecircularlabels0–2 onlyinvolvesasinglewayofrepresentinginstantiation,whereasthemodelinFig.1 usesbothUML-instantiationandauser-modeledformofinstantiation.InFig.2,all UMLinstantiationrelationshipshaveanontologicalinterpretation,whereasinFig.1 therelationshipsfromthedomaininstancestotheirUMLclasseshavealinguisticin- terpretation1andonlytheinstantiationrelationshipsfromthedomaintypestotheir UMLclassesareontological[13].Inshort,themodelinFig.2successfullyavoidsthe accidentalcomplexityintroducedbythemodelinFig.1.OnecanexpecttheFig.2 modeltobetransformedintotheFig.1modelwhenproceedingfromaproblemspeci- ficationtoasolutionexpressedwithinaframeworkwithatwo-levellimitation,butone shouldneverregardthemodelofFig.1asafaithfulrepresentationoftheproblemand itsdomain. Allowinguserstomodelatmorethantwolevelsisstraightforwardlyachievedwith theOrthogonalClassificationArchitecture,aninfrastructureproposalwhichcleanly separatesthelinguisticandontologicaldimensionsofinstantiation,supportinganar- bitrarynumberofontologicallevels[2,3].Thisinfrastructureisalsoanidealchoice 1Linguisticinstantiationoccursbetweenelementsoflanguageusage(e.g.,modelelements)and elementsoflanguagedefinition(e.g.,metamodelelements). 28
VI ProductType name:String
ProductType name:String ComputerModel processor:String
MonitorModel size:String model types
model metatypes
domainty pes
model instances domain in stance s domai
nm eta type s
ct1:ComputerModel name="PCstandard" processor="3.1Ghz"
mt1:MonitorModel name="Flat19" size=19
2 1 c1:Computer0 m1:Monitor Fig.2.UsingThreeUserModelingLevels forsupportingtheconceptofa“UnifiedModelingLibrary”,assuggestedinsection3. Furthermore,themostexpressivewaytoequipatypemodelwithproblem-orientedcat- egorymarkers(seetheparagraphonthepollutingtransformationphenomenonabove) istoletmodelelementsbeinstancesofdomainmetatypes,asshowninFig.2. 4Conclusions Inthispositionstatement,Ihavefocussedonanumberofshortcomingsassociated withtoday’smodelinglanguages,inparticulartheUML.Iclaimedthatthespecificity dilemma,thespecificationdecompositionproblem,thepollutingtransformationphe- nomenon,andatwo-levellimitationpreventtoday’smodelinglanguagesfromopti- 29 VII mallysupportingMDD.Aslongastheydonotsufficientlyaddresstheseissues,they willseverelyhamperthesuccessofMDDandrestrictittoapplicationareaswheretheir disadvantagesarenotapplicableorcanbetolerated. Interestingly,ifusedinconjunctionwiththeconceptofa“UnifiedModelingLi- brary”,theOrthogonalClassificationArchitectureaddressesthreeofthefourafore- mentionedshortcomings. References 1.C.AtkinsonandT.Kühne.Aspect-orienteddevelopmentwithstratifiedframeworks.IEEE Software,20(1):81–89,January/February2003. 2.C.AtkinsonandT.Kühne.RearchitectingtheUMLinfrastructure.ACMTransactionson ModelingandComputerSimulation,12(4):290–321,Oct.2003. 3.C.AtkinsonandT.Kühne.Conceptsforcomparingmodelingtoolarchitectures.In L.Briand,editor,ProceedingsoftheACM/IEEE8thInternationalConferenceonModel DrivenEngineeringLanguagesandSystems,MoDELS/UML,pages398–413.Springer Verlag,Oct.2005. 4.C.AtkinsonandT.Kühne.Atouroflanguagecustomizationconcepts.InM.Zelkowitz, editor,AdvancesinComputers,volume70,chapter3.AcademicPress,Elsevier,June2007. 5.C.AtkinsonandT.Kühne.Reducingaccidentalcomplexityindomainmodels.Journalon SoftwareandSystemsModeling,toappear2008,DOI:10.1007/s10270-007-0061-0. 6.F.P.Brooks.Nosilverbullet:essenceandaccidentsofsoftwareengineering.Computer, 20(4):10–19,1987. 7.M.Broy.Compositionalrefinementofinteractivesystemsmodelledbyrelations.Lecture NotesinComputerScience,1536:130–149,1998. 8.P.Coad.Object-orientedpatterns.CommunicationsoftheACM,35(9):152–159,Sept.1992. 9.S.Cook,A.Kleppe,R.Mitchell,B.Rumpe,J.Warmer,andA.Wills.DefiningUMLfamily membersusingprefaces.InC.MinginsandB.Meyer,editors,ProceedingsofTechnologyof Object-OrientedLanguagesandSystems,TOOLS’99Pacific.IEEEComputerSociety,1999. 10.G.Engels,A.Förster,R.Heckel,andS.Thöne.ProcessmodelingusingUML.InM.Dumas, W.vanderAalst,andA.terHofstede,editors,Process-AwareInformationSystems,pages 85–117,NewYork,2005.WileyPublishing. 11.W.G.Griswold,R.Wolski,S.B.Baden,S.J.Fink,andS.R.Kohn.Programminglanguage requirementsforthenextmillennium.ACMComputingSurveys,28(4es):194–194,1996. 12.R.JohnsonandB.Woolf.Typeobject.InR.C.Martin,D.Riehle,andF.Buschmann, editors,PatternLanguagesofProgramDesign3,pages47–65.Addison-Wesley,1997. 13.T.Kühne.Mattersof(meta-)modeling.JournalonSoftwareandSystemsModeling, 5(4):369–385,2006. 14.OMG.MDAGuideVersion1.0.1,2003.Version1.0.1,OMGdocumentomg/03-06-01. 15.OMG.UnifiedModelingLanguageSuperstructureSpecification,Version2.0,OMGdocu- mentformal/05-07-04,2005. 16.OMG.Metaobjectfacility(MOF)2.0corespecification.OMGdocumentformal/2006-01- 01,2006. 17.J.-P.Rosen.HOOD—AnIndustrialApproachforSoftwareDesign.ISBN2-9600151-0-X, 1997. 30
![Figure 3. Composition calculator in Eclipse 4. Related work Anneke Kleppe in [7] describes an open environment for model transformations in which users may combine the available tools that implement transformations and apply them to models in various la](https://thumb-eu.123doks.com/thumbv2/1library_info/5219234.1669492/71.892.184.662.706.1089/composition-calculator-describes-environment-transformations-available-implement-transformations.webp)
