Functional metamodels for systems and software Laurent Thiry, Bernard Thirion
To cite this version:
Laurent Thiry, Bernard Thirion. Functional metamodels for systems and software. Journal of Systems and Software, Elsevier, 2009, 82, pp.1125-1136. 10.1016/j.jss.2009.01.042. hal-00864184
HAL Id: hal-00864184 https://hal.archives-ouvertes.fr/hal-00864184 Submitted on 20 Sep 2013
HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Manuscript Click here to view linked References
Functional metamodels for systems and software Laurent Thiry, Bernard Thirion ENSISA, 12 rue des fr`eres Lumi`ere - 68093 Mulhouse (France)
Abstract
The modeling, analysis and design of systems is generally based on many formalisms to describe discrete and/or continuous behaviors, and to map these descriptions into a specific platform. In this context, the article proposes the concept of functional metamodeling to capture, then to integrate modeling languages. The concept offers an alternative to standard Model Driven Engineering (MDE) and is well adapted to mathematical descriptions such as the ones found in system modeling. As an application, a set of functional metamodels is proposed for dataflows (usable to model continuous behaviors), state-transition systems (usable to model discrete behaviors) and a metamodel for actions (to model interactions with a target platform and concurrent execution). A model of a control architecture for a legged robot is proposed as an application of these modeling languages.
Key words: System modeling, functional metamodeling, Model Driven Engineering (MDE)
1. Introduction points of view, Figure 1. The most concrete is the one of systems experts that model, analyze or de- The analytical and computational modeling of sign systems. To do this, they need tools that are systems generally requires the composition of var- developed by software experts ; the tools have gen- ious models and formalisms for their study, their erally a ”formalism inside” (e.g. matrix algebra analysis or their design, Vangheluwe and de Lara for matlab). At a more generic level, recurrent ele- (2003). For example, dataflows, used to describe ments, on which the preceding tools are based, are continuous behaviors, must be composed with dis- capitalized by models experts ; in particular, the crete elements to capture operating modes, and latter provide concepts and means to manipulate with more software oriented elements, Henzinger modeling languages and models that will be used and Sifakis (2007). Moreover, computational mod- by software experts to develop more easily/quickly els can be described using an imperative language, specific tools, that will be used by systems experts. an object oriented language, a functional language, As a result, MDE proposes a set of dedicated etc. languages: Meta Object Facility (MOF) to specify The Model Driven Engineering (MDE) commu- metamodels, Object Constraint Language (OCL) nity has brought a reflection on what ”models” to add semantics or constraints on modeling el- of systems, or models of modeling languages also ements, Query/View/Transformation (QVT) to called metamodels are and what the relations be- relate (meta)models, etc. The description of for- tween models also called model transformations malisms inside MDE is generally object-oriented. are, Mellor et al. (2003). MDE is based on three The paper proposes an alternative approach that is function-oriented and is named functional meta- modeling. This approach has an impact on the three Email addresses: [email protected] (Laurent Thiry), [email protected] (Bernard Thirion). layers of Figure 1 and it proposes new means to
Preprint submitted to Journal of Systems and Software 11 December 2008 and comprehensible way, the elements presented al- low the study of a wide range of systems such as the legged robot of part 5. And in contrast to ded- icated tools like Matlab/Simulink 1 , the framework System Experts Tool designers Generic environment M1 M2 M3 providers proposed can be easily adapted or extended. The paper is divided into six parts. Part 2 in- Model, Analyze Operationalize Propose troduces the concepts of systems, models and & Design & Integrate modeling (Systems) (Formalisms) architectures metamodels. Part 3 details the main contribu- tion of the paper with functional modeling ; i.e. <
Up representationOf u xn+1 = a.xn + b.un y elementOf elementOf y = c.x + d.u min max n n n Modeling Modeling Down Language 1 Language 2 (P) (Q) transformation
Fig. 3. Composition of continuous, discrete and concurrent Fig. 4. Extract of MDE megamodel. models. Metamodels can also be used to configure generic (meta) modeling environments, proposed by the 2.2. Model Driven Engineering (MDE) MDE community, in order to get tools dedicated to a specific formalisms (i.e. to create and to ma- Model Driven Engineering (MDE) proposes con- cepts and tools to capture, then to integrate, mod- 2 www.omg.org/mof/ nipulate models for these formalisms). Examples restricted set of concepts, are preferred. Moreover, of metamodeling tools dedicated to systems are all these languages are not sufficient to describe the Generic Modeling Environment GME, Dubey other parts of MDE such as concrete syntaxes of (2005), and Atom3, Vangheluwe and de Lara (2003). the models or means to transform models ; so, To explain the concept of metamodel, Figure 5 other languages have to be considered (e.g. the specifies an example of a possible metamodel for Query/View/Transform - QVT, for model trans- block diagrams. Block diagrams are used to model formations). The use of a restricted set of concepts continuous dynamical systems with signals and to specify models, metamodels and model transfor- transfer functions on these signals. The diagram of mations will be helpful and is the main concern of Figure 3 shows an example of block diagram that the article. In contrast to classical metamodeling, conforms to this metamodel. A transfer function f which exposes the structure of the abstract syntax is represented graphically by a block with inputs of a modeling language through MOF, EMOF or (corresponding to the arguments of f), and outputs UML diagrams, the proposed approach tries: 1 - (corresponding to the results of f). Transfer func- to hide the structure following the concept of ab- tion composition is obtained by linking the output stract data types, Guttag (2002), and 2 - to specify of a block to the entry of another block. Blocks can transformation models by sets of equations. be classified into two categories: basic blocks, which Before presenting the concept of functional meta- relate entries to outputs with algebraic equations modeling in part 3, part 2.3 describes what is called (Figure 2) and composite blocks whose internal functional modeling. structure is given by interconnecting more simpler blocks. Composites are useful to organize models in a hierarchical way. The concepts that appear in 2.3. Functional modeling this description can be represented on a class dia- gram (Figure 5): modeling elements/concepts are As shown in the previous sections, systems and represented by classes and relationships between models can be described in various manners. In par- these concepts are represented by associations (be- ticular, systems and models can be mathematically tween the corresponding classes), or compositions specified by sets and relations (or functions) that (marked by a diamond). can be represented visually by graphs. For instance, the behavior of a system can be modeled by a set of Basic Composite states and transitions, and the structure by a set of objects and links. The functional paradigm, used by N Equation Block functional programming languages, is based on this N N kind of description. More precisely, a function f will N Input Link Output correspond to a particular relation between two sets, also called data types (A, B) and will be written f : Fig. 5. Metamodel for block diagrams. A → B. A datatype will correspond to a set of func- tions to build values, to compose values, or to map Well-formed block diagrams are defined by the values into values of another type. A function is as- previous metamodel plus a set of logical expressions sociated to a definition f(x) = y and to applications expressed, for instance, with the Object Constraint f(z) whose semantics consists in evaluating the ex- Language (OCL). For instance, a rule saying that an pression y with the occurrences of x replaced with input can be connected to one, and only one, output z. The expression y consists of (constant) values or is formalized by the OCL expression: other functions. Functions can be composed with a context i:Input ”dot” operator defined by (f ◦ g)(x) = f(g(x)). inv OneConnection: i.link->size()==1 Functional programming languages are based on the previous elements plus a set of, generally unrec- The languages used to specify meta-models (i.e. ognized, features, Wadler (1996). The most impor- here MOF and OCL) are described by reference tant ones are: documents of a thousand pages ; which makes them – The definition/use of functions, called construc- difficult to use in practice. As a consequence, other tors, that are not necessarily attached to an ex- languages (such as Essential MOF - EMOF, or pression. In particular, all constants (e.g. 1 : N) Eclipse Modeling Framework - EMF), based on a can be modeled by constructors. – The possibility to pass functions as arguments or mult : Exp × Exp → Exp as result of other functions. The derivative opera- tor is an example of such a function: if f is a func- Expressions are defined using function applications. tion from R to R (i.e. R → R) then the derivate For example, a model of e = 1+(2×3) will be simply: is a function derivate :(R → R) → (R → R). e = plus(value(1), mult(value(2), value(3))) – The capability to evaluate a function partially, i.e. a function with two arguments f :(A, B) → C Figure 6 shows a possible object-oriented model for can be replaced by a function with one argument the example. The type Exp and the three construc- that returns another function of one parameter, tors are mapped into classes ; the values used by the i.e. f ′ : A → (B → C). Thus, if f requires two ′ constructors are mapped to attributes or composi- arguments (a, b) then f requires only one argu- tions (e.g. left/right expressions for binary opera- ments a ; the result can be applied to another ar- tors P lus/Mult). The figure also presents an asso- gument b when necessary. This property can be ciation (f) to model a transformation (and a func- used to define generic functions that can generate tion) from expressions to any type T . a set of more specific functions.
– If data types can be composed (e.g. with the f left, right T Exp cartesian product A × B, or (A, B)), then func- 2 tions can be composed too ; e.g. if f, g are func-
tion then (f, g) is also a function and (f, g)(x) = :Plus Value Plus (f(x), g(x)). This possibility is interesting to (idem Mult) realize parallel computations, Harisson (2006). 1:Value :Mult As a consequence of these powerful capabilities, most functional programming languages are based 2:Value 3:Value 1+(2x3) on a few constructs (to define new functions or to use previously defined functions) plus a library of Fig. 6. Models of arithmetic expressions. generic functions. All the possibilities offered by the functional paradigm will be used in the rest of the The example can be translated into Haskell us- paper to describe (and to integrate) modeling ele- ing a type definition (with the keyword data) that ments and will be called functional (meta)modeling. groups together the three constructors (constructors The advantage of the approach is to be based on a have a name followed by a set of parameters ; the small number of concepts and to be well adapted result is to the left side of =, here Exp): to formalisms based on mathematical descriptions (like the ones found in system modeling (2.1)). data Exp = Value Integer | Plus Exp Exp Another advantage of the concept is to be nat- | Mult Exp Exp urally supported by functional programming lan- guages. In particular, the functional models (and -- This definition is equivalent to metamodels) presented can be translated into the -- Value :: Integer -> Exp modern functional programming language Haskell, -- Plus :: Exp ->(Exp -> Exp) -- Mult :: Exp ->(Exp -> Exp) Hudak et al. (2007). Haskell is based on very few constructs, Bird (1998). A data type corresponds to e = Plus (Value 1) (Mult (Value 2) (Value 3)) a set of constructor functions and functions on this data type are defined by pattern matching, i.e. one Notes. First, as a convention, mathematical mod- rule for each constructor. els will be in italics (e.g. value, plus, Exp, etc.) and As an illustration, basic arithmetic expressions Haskell programs will be written using monospace (Exp) can be specified following the principle of font as above. Second, parenthesis will be used to abstract data types, Guttag (2002). V alue lifts avoid ambiguities and f(x) ≡ f x ≡ (f x). Integers into Exp, and plus/mult composes two Now, with this model, all functions on arithmetic expressions. expressions, i.e. f : Exp → T , can be defined by three equations (i.e. one for each constructor) and three parameters : g : N → T (used to transform value : Integer → Exp V alue) and h, i : T ×T → T (to transform Plus and plus : Exp × Exp → Exp Mult). As an example, the evaluation of arithmetic expressions can be specified by the function eval : 3. Functional metamodeling Exp → N : 3.1. Presentation eval (Value v) = id v = v eval (Plus x y)= (eval x) + (eval y) eval (Mult x y)= (eval x) * (eval y) Functional metamodeling is based on a general- ization of the approach used to specify arithmetic The function lifts the three constructors into the expressions. More precisely, modeling languages will three functions (g = id, h = (+); i = (×)). So, eval be captured by sets of functions mi to construct is a particular case of the more generic function f models ; in the MDE context these sets will be con- defined by: sidered to be functional metamodels. The relations, or transformations, between metamodels will be de- f g h i (Value v ) = g v f g h i (Plus x y) = h (f g h i x) (f g h i y) fined in a way similar to the function f for the arith- f g h i (Mult x y) = i (f g h i x) (f g h i y) metic expressions: i.e. a generic model of transfor- mation will correspond to another set of functions eval = f id (+) (*) fi plus a set of equations (one for each function mi). Theses sets of functions can be represented on Figure 7 presents a graphical representation for a graph: types correspond to the nodes, and the these equations. Now, choosing other particular val- functions to the edges. For instance, Figure 7 pro- ues for (g,h,i) allows the definition of most functions poses another representation for arithmetic expres- on expressions. For instance, the code generation for sions ; the dotted parts represent the model Exp = a stack machine can be defined by: value, plus, mult, and the grey parts represent the generate = f (\v->"PUSH "+v) transformation f = g, h, i. The equations of the (\x y->x+y+" ADD") transformation represent the equalities between the (\x y->x+y+" MULT") paths on these graphs (i.e. f ◦ value = g and f ◦ plus = h◦(f ×f), that also corresponds to the equa- generate e == "PUSH 1 PUSH 2 PUSH 3 MULT ADD" tions of the preceding section f(value(v)) = g(v) and f(plus(x, y)) = h(f(x), f(y))). Thus, the functional model for arithmetic expres- sions is defined in a compact and formal manner f x f by four elements: value/plus/mult to build expres- Integer Exp x Exp T x T g sions, and f to transform expressions ; to do this, f value ! plus h / mult / i is parameterized by three functions (g, h, i) and all Exp T Exp T functions on expressions can be defined by choosing f f specific values for these parameters. Despite their interest, researches using functional Fig. 7. Graphical representation for expressions. paradigm in Model Driven Engineering for systems are not numerous. Among the latter, Mathaikutty Remark. From a more formal point of view, the el- (2005) proposes a set of (meta)models for the mod- ements presented can be explained in the context of eling and simulation of hybrid systems and Uustalu category theory, Walter (1992). However, an under- and Vene (2006) describe a framework for the mod- standing of the theory is not necessary to apprehend eling and analysis of continuous systems. The pro- the elements proposed. The only thing to remember posed functional metamodeling paradigm, based on is that diagrams correspond to equations and, with the previous concepts, tries to be more general by the proposition, to models, metamodels and trans- describing how functions can capture modeling lan- formations. The language used to describe equations guages, metamodels, models and model transforma- is defined by elementary functions f, g : T → T ′, tions. applications f(g), compositions f ◦ g, and products f × g. As an illustration, a UML object diagram can be built using three functions: to create a new empty diagram, to add an object to a diagram, and to add a link between two objects. The functions New, AddObject, AddLink will be defined in the functional language Haskell by a type Diagram sented in the following sections and will be applied and three constructors: in part 4 to a set of modeling languages for systems. data Diagram = New | AddObject String Diagram 3.2. Model for generic lists | AddLink String String Diagram -- This definition is equivalent to The behavior of a discrete time system can be -- New :: Diagram -- AddObject:: String->(Diagram->Diagram) described in various ways like, for instance, a se- -- AddLink :: String->(String->(Diagram->Diagram)) quence of values (xi) representing the state x at each instant i, or a sequence of values (ai) such k i Every sequence of actions to create a particular di- as x(n) ≈ Σi=0ai.n (for any instant n). Possi- agram can be modeled using partial evaluation (e.g. ble transformations between these models are in- AddObject o : Diagram → Diagram) and function terpolation and sampling. The previous models composition (◦). For instance, the following model (that will be detailed in part 4.1) are based on ∗ has two objects P roducer/Consumer and a link be- a common model (ai), also written A . A func- ′ tween these objects ; model extends model with a tional description of lists consists of two elements: Consumer object. empty : ∅ → A∗, to create an empty list, and add : A × A∗ → A∗, to add an element to a list of actions = AddLink "Producer" "Consumer" As. From a MDE point of view, {emty, add} corre- . AddObject "Consumer" . AddObject "Producer" sponds to the metamodel for lists and a model for model = actions(New) a particular list will be specified by a composition model’ = AddObject "Consumer" model of these functions. For instance, one = add 1 one = add 1 (add 1 one) = will be interpreted as an Functions on diagrams, and model transforma- infinite sequence of ”1”. The modeling language tions, will be defined by following the approach pre- captured by this metamodel will be the set of terms sented, with three equations (one for each construc- {empty, add a1 empty, add a2 (add a3 empty), }, tion). For instance, the function check returns True for any ai in A, and will serve, for instance, to if a sequence of actions is consistent ; i.e. the addi- model behaviors. A graphical representation of the tion of a new object into a diagram requires that this functional metamodel is presented on the left part object does not already exist, and the addition of a of Figure 8 (with πi the projections of the cartesian link requires that the extremities exist. The function product, e.g. π1 : A × B → A) ; the right part contains tests if an object belongs to a diagram. corresponds to an equivalent class diagram. contains :: Diagram -> String -> Bool tail A* List check :: Diagram -> Bool !2 empty add check (New) = True check (AddObject o d) = not (contains d o) ! AxA* Empty Add && (check d) !1 check (AddLink o o’ d)= (contains d o) head && (contains d o’) A A -- check(model) == True -- check(model’)== False , Consumer already exist ! Fig. 8. Representation of generic lists A∗. Rather than defining specific metamodels (such as the one of object diagrams), the paper will fo- As explained, functions can be used to define generic transformations. More precisely, the func- cus on two fundamental (meta)models for lists and ∗ graphs. Indeed, most modeling languages used to tion f : A → T , defined by a couple (v, g), such describe systems are based on these two concepts. as f(empty) = v and f(add(h, t)) = g(h, f(t)), For instance, behaviors are generally represented by will model all common transformations on lists. sequences (of states), block diagrams used for mod- Figure 9 presents a representation of this trans- formation (and of the previous equations). Sam- eling the structure of systems or state-transition ∗ ∗ diagrams used for modeling discrete behaviors are ple transformations are: map(l): A → B graphs, etc. The models for lists and graphs are pre- with v = empty and g(h, t) = add(l(h), t), and select(p): A∗ → A∗ with v = empty and g(h, t) = if p(h) then add(h, t) else t. The function map -- Empty :: (List a) applies a function l to each element of a list and -- Add :: a -> (List a -> List a) select extracts the elements of a list that satisfy a f v g Empty = v property p. f v g (Add h t) = g h (f v g t) Remark. The composition of the preceding func- tions, i.e. (map(f).select(p))(xs), can be used to map l = f Empty (\h t -> Add (l h) t) model sets such as {f(x)◦x ∈ xs∧p(x)}. In Haskell, select p = f Empty (\h t -> if (p h) then Add h t these expressions are encoded by the syntactic sugar else t ) [ f(x) | x < − xs, p(x)] and are commonly used to model :: List Integer express more easily some transformations on lists. model = Add 1 (Add 2 Empty) map (+1) model == Add 2 (Add 3 Nil) f f map odd model == Add 3 Empty T A* T
!2 v empty add g id id x f ! ! AxA* AxT 3.3. Model for graphs
!1 f o empty = v o id = v The second metamodel used by the article, and f o add(h,t) = g (h, f(t)) A more generally in MDE and systems modeling, is the one of graphs. Indeed, most visual models can ∗ Fig. 9. Generic transformation on lists f : A → T . be represented by a graph. For instance, MOF class diagrams are graphs whose nodes correspond to The equations used to formalize f can be used to classes, and edges to relations between classes (i.e. prove properties attached to a particular transfor- inheritance, association, composition, etc.), state- mation ; for instance, it can be proved that map(f)◦ transition diagrams are graphs whose nodes are map(g) = map(f ◦ g). Some interesting properties states and edges are transitions, etc. offered by f are the possibility to lift functions A → ∗ ∗ In practice, a graph can be specified by a list of B into functions A → B (with map), or the capa- ∗ ∗ nodes A , a list of edges B , and a list of relations bility to generalize binary functions A×A → A into ∗ ∗ between nodes and edges (A × B × A) . Figure 10 n-ary functions A → A (e.g. a Σ expression will be presents a graphical representation of this functional modeled by sum = f 0 (+)). These capabilities will metamodel and the code below proposes a Haskell be used by the functional metamodel proposed in implementation. the next part for dataflow and block diagram meta- models. data Graph a b = Graph (List a) The functional metamodel proposed for lists (and (List b) more generally for all functional metamodels pre- (List (a,b,a)) sented in the paper) is: 1) compact - here, there An example of graph is the model on the left part are only three elements to know: empty/add and f, 4 2) formal - the equations for f can serve to prove of Figure 8 that can be translated to : properties of transformations, Doets and van Eijck type Model = Graph Type Function (2004), and 3) attached to a visual representation, type Type = String Figure 9. The metamodel can be encoded directly type Function = String into Haskell and can serve to capitalize mathemati- cal models based on sets or sequences 3 . fig1 :: Model fig1 = Graph [ "{}" , "A" ,"A*" ,"AxA*" ] The following code gives an interpretation of the [ "empty", "add" ,"pi1","pi2" ] preceding equations into Haskell ; the reader will [ ("{}" , "empty","A*") note the similitude with the metamodel for arith- , ("AxA*", "add" , "A*") metic expressions. , ("AxA*", "pi1" , "A" ) , ("AxA*", "pi2" , "A*") data List a = Empty ] | Add a (List a) -- or equivalently 4 The notation [a, b, ...] is a syntactic sugar for 3 These elements are lists with extra properties add(a, add(b, ...)). As for lists, there is a generic transformation f represent discrete behaviors, and for actions to rep- ′ defined by a couple of functions: f1 : A → A and resent interactions and concurrent executions. Con- ′ f2 : B → B , Figure 10. Using the function map, tinuous behaviors can be described numerically (4.1) this transformation becomes: or analytically (4.2). Discrete behaviors can be de- scribed from an implementation point of view using f :: (a->a’)->(b->b’)->(Graph a b)->(Graph a’ b’) state-transition systems (4.3) or from a specification f f1 f2 (Graph as bs rs) = Graph as’ bs’ rs’ where as’ = map f1 as point of view using linear temporal logic formulae bs’ = map f2 bs (4.4). Section 4.5 proposes an implementation model rs’ = map f3 rs that facilitates the deployment of the previous spec- f3 (x,y,z) = (f1 x, f2 y, f1 z) ification models onto a target platform. An application of this transformation can be found in the domain of concurrent processes, to 4.1. Dataflows express specific operators such as relabeling or par- allel composition, Winskel and Nielsen (1995). The Dataflows are a standard in the context of discrete second part of Figure 10 presents an application of time dynamical systems, Thielemann (2004). This graph transformation for the relabeling operator. kind of model specifies a set of relations between sequences of elements called ”flows” or ”signals” ; Graph a sequence is defined by a list (3.2). As explained nodes relations edges in part 3, sequences can be defined by a functional map !1 map !2 A* (AxBxA)* B* metamodel (i.e. a set of functions to build and to map !3 map f1 map f2 f transform sequences). Then, this metamodel can be implemented into the functional language Haskell A'* (A'xB'xA')* B'* and used to model continuous behaviors/systems. Graph' More precisely, a flow is either a sequence of ele-
c ments (e.g. numerical values), or a function that 0 computes an element depending on time, Lee and a Varaiya (2003). For example, a flow representing a b 2 unit step can be described either by the sequence 1 f1(0)=2, f1(1)=2 step = add 1 step, or by the function step (time) = f2(a)=c, f2(b)=c 1. To get the numerical value of this flow (or signal) at an instant t, it is possible to use a get operator Fig. 10. Representation of graphs (gray part), graph trans- (!!), i.e. step !! t for the first representation, or the formations f, and an example. function application step (t) for the second repre- The next part presents a family of functional sentation. As a remark, the first representation cor- metamodels dedicated to system modeling. These responds to an infinite flow: reducing step leads to metamodels are similar to (and are based on) the step = add 1 (add 1 ...). In standard Haskell, the 5 ones presented for lists and graphs. Next, the result- previous function will be written step = 1 : step ing framework is used in part 5 to model a control and can be generalized by a function that lifts any architecture for a legged robot. value into a flow, i.e. lift0 x = x :(lift0 x). Higher- order functions, i.e. functions taking other functions 4. Functional metamodels for systems as argument or as result (e.g. f or map), are used to lift operators and functions on values into func- tions on flows. The application of these higher-order The models of systems presented in part (2.1) can functions to a particular function will be used to be formalized by metamodels (2.2) that can be spec- model basic blocks found in dataflow models. As an ified by sets of functions (2.3). This proposition has illustration, a model for a block that computes the lead to the concept of functional metamodeling de- absolute value (abs) of a flow whose first value is x tailed in part 3. and following values are given by another flow xs, As an application of the proposition, this part presents a framework (i.e. a set of concepts and 5 For readability reasons, the operator (:) will be preferred tools) for dataflow models used to represent contin- to the binary function and constructor add, i.e. x : xs ≡ uous behaviors, for state-transition systems used to add x xs. is abs (x : xs) = |x| : abs xs, what can be general- (i.e. transformations on flows such as lifti, and ized with abs = lift1 (||) where lift1 f (x : xs) = blocks) are now defined by a single rule/equation as (f x):(lift1 f xs). The function lift1 is similar to illustrated by the functions delay x0 or gain k below. the function map defined in part 3.2 and any unary function on a value can be lifted using lift1. In a -- specification of Flow and Block data Flow a = F a (Flow a) similar manner, a function lift2 is defined for binary -- i.e. F :: a -> (Flow a -> Flow a) functions or operators (with lift2 f (x : xs)(y : ys) = (f x y):(lift2 f xs ys)), a function lift3 for type Block a b = Flow a -> Flow b ternary operators, etc. In dataflow models, flows can be composed or -- examples of basic blocks delay, gain :: a -> Block a a transformed using blocks. A block is either a primi- delay x0 = F x0 tive ”function” (e.g. add, integrate, multiply or gain, gain k = lift1 (*k) delay, etc.), either a ”composition” of more simple blocks. Figure 11 presents an example of a dataflow lift1 f (F x xs) = F (f x) (lift1 f xs) model for a first-order system. add :: Block (a,a) a add = lift2 (+) order1 u x' x y step 1 gain b add delay 0 gain c lift2 f (F x xs) (F y ys) = F (f x y) (lift2 f xs ys) gain a -- example of composite block firstOrder a b c u = y Fig. 11. Example of a dataflow model. where x = delay 0 x’ x’ = add (gain a x) (gain b u) The previous description is fundamentally ”func- y = gain c x tional” in the sense that flows are functions from in- stants to values, and blocs are functions from flows Despite its simplicity, this functional metamodel to flows. By considering discrete time, a flow will be allows the modeling and the simulation of most of simply modeled by a list of values A∗, and blocks discrete time systems. As an illustration, the follow- by functions A∗ → B∗, A∗ × B∗ → C∗, etc. For ing model describes how to get the first values of instance, a step generator that returns a constant the response of a first order system to a unit step. value will be modeled by step : R → R, a delay These values can be saved into a file and then edited whose initial value is z0 by delay z0 : R → R, an using a spreadsheet to draw the systems’ behavior ; adder by add : R × R → R, etc. A graphical repre- figures 14 and 19 have been obtained in this way. sentation of the functional metamodel is presented on Figure 12. system :: Block Float Float system = firstOrder 0.9 0.1 1.0
Flow u, y :: Flow Float
2 value():A u = step next():Flow where step = lift0 1.0 lift0 v = F v (lift0 v) y = system u Step Add ... Delay y == [0, 0.1, 0.19, 0.27, 0.34,
Thus, the definition of a modeling language ded- Fig. 12. Metamodel for dataflows. icated to discrete time systems leads to a set of More precisely, the functional metamodel pro- functions {step, gain, delay, add etc.}, that can posed for dataflows is based on the one of list (3.2). be composed and then evaluated to get the behav- The difference between lists and flows is that the iors of these systems. All the functions are based on latter are not necessarily of finite length (i.e. flows generic functions lifti that model transformations do not have the possibility to be empty). To make on flows. A change on the equation of lifti leads to this distinction, the functional metamodel of flows is other semantics and other possible metamodels. In restricted to one constructor F that plays the same particular, the function lift0 : A → List(A) can be role as add. As a consequence, functions on flows defined by lift0 v = v :(lift0 v) or by lift0 v = v : (lift0 0). The first equation is used in this section analytical solution of the differential equation (E0) i for numerical models of behaviors, and the second : p(n) = !i(−n) /i!). equation is used in the next section for analytical The approach followed for continuous systems models of behaviors. with the definition of a modeling language and a functional metamodel will be considered for discrete state behaviors in the next section. 4.2. Analytical models of continuous behaviors 4.3. State-Transition Systems A dataflow model is generally a graphical repre- sentation of a finite difference equation or of a differ- ential algebraic equation (see 2.1) ; the basic blocks Discrete behaviors are generally represented by correspond to the mathematical operators used in State-Transition Systems (STS). An sts can be mod- this equation. The semantics used in the previous eled by a graph (3.3) on which a node corresponds to section consists in computing the successive values a configuration (or State) of a system at a given in- of a flow using other flows or using the preceding val- stant, and a transition to a change of this configura- ues of the considered flow. The trajectory/behavior tion when an event occurs. Block Q on Figure 3 gives of a system corresponds to these successive values. an example of sts with two States Q = {Up, Down} Another approach to compute the behavior is to and two events E = {min, max}. To be able to inte- use mathematical series. This change in the interpre- grate discrete behaviors with continuous behaviors, tation of dataflow models lies essentially in the man- an sts is modeled by a block with an input flow for ner a value is lifted: in dataflow model, a constant events and an output flow for values generated by value v is transformed into a constant flow [v, v, v, ...] the sts. In the previous example, the input is y and ; in series based models, a value v is transformed the events are {min = y < 0.1, max = y > 0.9} into a list of coefficients for the series, i.e. [v, 0, 0, ...]. ; the output is a continuous value u such as u = 1 More precisely, a behavior is derived from a sequence when the current state is Up, and u = 0 when the state is Down. of values (vi) ; the state at the instant n is then vn ∞ i With the proposition, a functional metamodel for with the dataflow interpretation, and !i=1 vi × n with series. As for flows, series can be described us- this definition of STSs will correspond mainly to a ing the lists’ metamodel (3.2): a list (add x xs), also current state s and a transition function t : State × written (x : xs) in Haskell, will correspond to a poly- Event → State×V alue ; i.e. considering the current state s and an input event e, t(s, e) will return a nomial p(n) = v0 + n × vs where vs is another se- ′ ′ ries (and another polynomial). Operators on series couple (s , v) where s is the next state and v the are expressed in the same way as basic blocks in the output value. This model has to be completed by a functional metamodel for dataflows. As an illustra- semantic function sem describing how the values of the input/output flows and the evolution of the sts tion, the integration of a behavior (vi) defined by can be linked together. The functional metamodel " (vi) = [0, v0, v1/2, v2/3, ...] will be modeled by the following function: proposed for STS is then defined in Haskell by the following code and a graphical representation of the integral (vs) = 0:(integral’ vs 1) functional metamodel is proposed on Figure 13. integral’ (v0:vs) n = (v0/n):(integral’ vs (n+1)) data STS = STS State Transition type Transition = (State,Event) -> (State,Value) As an application, a first order system modeled by the differential equation (E0) p′ + p = 0 with sem :: STS -> Flow a -> Flow b sem (STS s t (F i is)) = F o os an initial condition p(0) = 1 can be represented where (s’,o) = t (s,i) by p(n) = p(0) + " p.dn ; and this expression can os = sem (STS s’ t is) be modeled with the preceding function by : p = add (value 0) (integral p). The function value is As an illustration, the model below describes how then based on a new interpretation of lift0, i.e. value the process Q of Figure 3 can be modeled with this v = v:(lift0 0). The function add is based on the ex- new metamodel : t corresponds to the transition pression lift2 used for dataflows. As a result, the function, q to the sts with an input flow y, and u to successive values returned by the Haskell interpreter the output flow that will be connected to the first is then [1, −1, 1/2, −1/6, ...] that correspond to the order system presented in 4.1. sem an example of transformation, the function (sat p): Flow STS input F orm → Bool checks if a path p satisfies a formula. A path models a particular behavior and is repre- N N N s e sented here by a sequence (3.2) of states where each State Transition Event t state is labeled by a set of properties (represented here by strings). This model also describes how to Fig. 13. Metamodel for state-transitions systems. build syntactic sugars (globally and imply) on the top of the previous elements. t :: Transition type Property = String t (0,y) = if y>0.9 then (1,0) else (0,1) type State = List Property t (1,y) = if y
0 n imply f g = Or (Not f) g 40 80 Figure 15 presents a graphical view of this meta- Fig. 14. Output y(n) for the example. model. Form becomes a class with an operation sat(t : T race): Boolean and F T rue, P roperty, Not, etc. become subclasses ; the implementa- 4.4. Specification of temporal properties tion of sat is then described by the previous code/equations. This kind of diagrams establishes As a complement to the previous section, and to a bridge between the elements proposed and the show the benefit brought by the concept of func- standard MDE approach. As an application of this tional metamodeling, this part proposes a modeling metamodel, the following model gives an example of language dedicated to requirements. Indeed, the de- test for the expression (P ush ⇒ X Move) U Stop). velopment process for software is generally based on successive steps beginning with requirements (or ex- path = [["Push"],["Move"],["Stop"]] pression of what a system must do/be), followed by form = U (imply (FProp Push) (X (FProp Move))) design and tests (or formal proofs), and terminated (FProp Stop) by implementation and deployment on a target ar- chitecture. sat path form == True Properties found in requirements can be formal- ized with temporal logic formulae (F orm) - Clarke et al. (2000), and the following metamodel specifies Form 2 a subset of the language used to express these for- sat(path):Boolean mulae with: constant (F T rue), atomic propositions (F P rop), classical operators (Not, Or) and tem- poral operators (neXt, Until). These elements are FTrue FProp Not ... Until modeled by functions (e.g. Not : F orm → F orm) that are defined in Haskell by the following code. As Fig. 15. Metamodel for LTL Formulae. Thus, the functional metamodels proposed can be used to model and to simulate either contin- type Process = List Action uous behaviors, or discrete behaviors, or continu- prod,cons :: Process ous+discrete behaviors. However, these metamod- prod chan = p 0 els do not take into account implementation details where p v = (put chan v) : (p (v+1)) such as the interactions with an environment or a cons chan = display : cons target platform on which models will have to be de- where display = bind (get chan) (put output) ployed. To go beyond this limitation, the following section presents a functional metamodel for actions The formalization of processes by the way of ac- and interactions. tions makes it possible to define a particular exe- cution models such as interleaving ; and a function par below proposes an implementation of this ba- 4.5. Actions and concurrency sic model of concurrency. The function sequence ex- ecutes a sequence of actions (i.e. a single process) The concept of action, found in imperative pro- and the function run is a particular use of sequence gramming languages, can be modeled by functions that executes n actions of a process. The function transforming a state, i.e. the execution environment main is an implementation model for the system at a given instant, into another state plus a result. producer||consumer: this function corresponds to An operator called bind is then defined to compose the interleaving of two concurrent processes/blocks actions sequentially and to retrieve a result ; bind is that exchange values by the way of channels (and similar to the operator (◦) used for function compo- shared variables) u and y. Calling ”run 10 main” sition. Basic (and concrete) actions are defined: get on an initial state ([ ]) returns the new state [(out- the value of a variable from the execution context, put,012345),(chan,5)] after executing 10 actions. and put of a value into an execution context. These elements are represented by the following functional parallel :: Process -> Process -> Process metamodel where an execution context corresponds parallel (x:xs) ys = x:(parallel ys xs) to a state defined as a list of couples (V ariable, sequence :: Process -> Action V alue) and an action is a function returning a value of type a and a new state. run :: Integer -> Process -> Action run n p = (sequence (take n p)) [] type State = List (Variable,Value) type Action = State -> (Value,State) main :: Process main = parallel prod cons get v vs = (findIn v vs,vs) put v e vs = ((),insert (v,e) vs) run 10 main == [(output,012345), (chan,5)] bind p f c = let (r,c’)=p c in f r c’ With the various functional metamodels, a soft- From now, the blocks presented on sections ware system would be defined by a set of processes 4.1 and/or 4.3 can be interpreted as (concurrent) that are modeled at a logical level by continuous processes ; a process being defined by a sequence or discrete blocks and flows (of values or events), of actions. These processes use the global state and at an implementation level by actions and and shared variables to communicate and to syn- processes. Figure 16 presents a graphical repre- chronize. Indeed, grouping together two processes, sentation of the functional metamodel usable to where (put v chan) is defined on the first and describe implementation models (i.e. models that (get v) is defined on the second, can be interpreted facilitate the deployment of the elements of parts by a sending of the value v into the communication 4.1 and 4.3 into a target architecture). channel chan. For instance, the processes P and Q At this point, the article has proposed the concept shown on Figure 3 communicate by the way of two of functional metamodeling that is detailed in part shared variables u and y. As another example, the 3 and that corresponds to the right part of Figure 1. producer-consumer model below describes a pro- The concept has been applied in this part to specify cess prod (and a block which generates a ramp, i.e. and to integrate modeling languages used in systems a flow: v=1:2:3:...) that emits values on chan, and a and software ; this corresponds to the middle part process cons which reads these values and displays of Figure 1. The next part will use these functional them. N 2 State Action Process between the legs is done using a signal S defined by two values : if leg i emits the event Can (resp. Cant) then leg (i+1) mod 6 can do the transition W ait → Put Get Bind Move (resp. can not do the transition). The state- N Var Sequence Parallel transition model describing the discrete behavior is represented on the upper part of Figure 18. The ini- Fig. 16. Functional metamodel for actions/processes. tial state is P ush and the transitions have three el- ements (in1, in2)/out where in2 is the signal com- metamodels in a more complete example and will ing from leg i − 1, and out is the signal emitted to corresponds to the left part of Figure 1. leg i + 1. In1 is used to control the position x and can take three values: min when a leg can not push 5. Application to a legged robot anymore (i.e. min = reachMin x), max when a leg can not move anymore (i.e. max = reachMax x), and = not (min or max). Using the functional 5.1. Description of the system metamodel for STS (4.3), the discrete behavior of a leg is represented by an sts composed by the initial The functional metamodels are used to describe state P ush and the transition function t (see Haskell the control of the locomotion of a legged robot (fig- model below). Let’s keep in mind that a transition ure 17), Thirion and Thiry (2002). The main blocks function takes two parameters (:the current state used to control this system are given by Figure 18. and the input event - here (x, Can/Cant)), and re- The displacement of each leg i (represented by dxi) turns two elements: the new state and the output is computed using the geometric and kinetic mod- values - here (Can/Cant,kx). The values kx are used els fi and the global speed vectors of the platform to control the trajectory of a leg (i.e. to compute ( v, ̟). This displacement is used by the leg con- new value of x for each leg i) ; they are detailed with troller ai, which provides the position xi of a leg. the dataflow model in the next section. The position depends on the operating mode: a leg can be on ground and push the platform, a leg can -- States be up and move, or a leg can wait to move. Indeed, a type P = (Float,Float,Float) -- Continuous data E = Push | Wait | Move -- Discrete control signal si is used to synchronize the legs and to keep the platform stable. More precisely, a leg i -- Events can move if, and only if, the legs (i ± 1) mod 6 are data S = Can | Cant not moving. reachMin, reachMax :: P -> Bool
-- State-transition model t :: Transition t Push (x,_) = if reachMax x then (Wait,(Can,k1)) else (Push,(Can,k2)) t Wait (x,Can ) = (Move ,(Cant,k3) t Wait (x,Cant) = (Wait,(Can ,k1) t Move (x,_ )= if reachMin x then (Push,(Can,k2)) else (Move,(Cant,k3))
sts = STS Push t
At this point, the function sem (4.3) is used to transform STSs into blocks (4.1) and to compute Fig. 17. Legged robot. the synchronization signals si (see below). The only thing that remains to be done is to precise how con- tinuous state xi is computed and what the use of 5.2. Functional model the parameters kx is. The trajectory of a leg can be split into three equations xi+1 = fk(xi), i.e. one A leg is defined by a continuous state correspond- equation for each discrete state, and these equa- ing to the position P = R3, and by a discrete state tions can be merged with f(x) = kp.fP ush(x) + E = {P ush, W ait, Move}. The synchronization kw.fW ait(x) + km.fMove(x) with kx ∈ {0, 1}. Thus, the values kx computed by each sts correspond to (_,_)/can k1 = (kp, kw, km) = (0, 1, 0), k2 = (1, 0, 0) and Push k3 = (0, 0, 1). Using the function map on lists (3.2), (min,_)/cant (max,_)/can it is possible to extract these values from the flow ∗ ∗ Move AWwaitait ki = (kp, kw, km) returned by each sts, e.g. kp = (_,can) map π1 ki with π1 :(A, B, C) → A. Finally, the /cant computation of the flow x is realized by a dataflow (_,_)/cant (_,cant)/can model composed with Gain, Add and Delay. The s6 x6 a6 a1 x1 functions fP ush and fMove correspond to geomet- ric transformations and are not detailed here ; the dx1 s5 s1 function fW ait shows that when a leg is waiting, its f6 f1 position p = (x, y, z) does not change. x5 a5 f5 (v,!) f2 a2 x2 -- Dataflow model f4 f3 -- Transformation of STSs into blocks s4 s2 (s1,k1) = sem sts (x1,s6) -- leg 1 (s2,k2) = sem sts (x2,s1) -- leg 2 x4 a4 a3 x3 (s3,k3) = sem sts (x3,s2) -- leg 3 s3 ... continousbloc continubehavior flot continouscontinu flow (s6,k6) = sem sts (x6,s5) -- leg 6 discretebloc behavior discret flot eventdiscret flow -- Extraction of the control flows k1p = map pi1 k1 Fig. 18. Model of the control architecture. k1w = map pi2 k1 k1m = map pi3 k1 -- same thing for k2,k3,...,k6 mode. At this point, the system has a characteristic -- Continuous behavior and dataflow model behavior (called tripod walking) where each group x1 = Delay x0 x1’ of legs (i.e. 1-3-5 and 2-4-6) alternates between P ush x1’ = Add (Gain kp (map fPush x1)) and Move. (Add (Gain kw (map fWait x)) (Gain km (map fMove x))) Patteleg6 6 fPush, fWait, fMove :: P -> P Patteleg5 5 fWait p = p Patteleg4 4
From now, the continuous state, i.e. the position Patteleg3 3 x of each leg i at the instant n, can be obtained with Patteleg2 2 (xi !! n). The discrete state can be obtained in a similar manner with (ki !! n) and using the preceding Patteleg1 1 rules (i.e. if the value is kp=(0,1,0) then the leg is 100 200 300 400 t (ms) pushing, kw then the leg is waiting, km then the leg is moving). Fig. 19. Behavior of the legged robot. Thus, the functional metamodels defined in part 5.3. Results 3, and the modeling languages captured in part 4, are well adapted to model/simulate systems that can have a complex behavior or structure. Figure 19 presents the behavior of the robot and the discrete state of the legs. A low level corresponds to P ush, a middle level to W ait and a high level 6. Conclusion to Move. At the origin, all legs push to their poste- rior extreme position (xmax on the Haskell model). This paper has proposed the concept of ”func- Reaching xmax, the legs 1-3-5 go into W ait mode tional metamodeling” and its application to a set of while the legs 2-4-6 go into Move mode. Legs 2-4- modeling languages for systems and software. As a 6 move to their anterior extreme position (xmin on final result, these languages have been used to model the Haskell model). Reaching xmin, the legs 2-4-6 go a control architecture for a legged robot with contin- into P ush mode, while the legs 1-3-5 go into Move uous and discrete behaviors that are implemented as concurrent processes. More precisely, with the References concept, modeling elements are described by sets of functions to create models, and a model of generic Bird, R., 1998. Introduction to Functional Program- transformation that is also a function. Thus, for- ming using Haskell, 2nd Edition. Prentice Hall malisms and their relations can be specified using PTR. a single but formal concept: the one of ”function”. Breton, E., Bezivin, J., 2001. Towards an under- This offers many advantages that are generally un- standing of model executability. In: International known. For instance, functions can be composed and Conference on Formal Ontology in Information passed as parameters of other functions (2.3). So, Systems. pp. 70–80. the paper has explained how these capabilities can Clarke, E., Grumberg, O., Peled, D., 2000. Model be used to capture and to integrate modeling lan- Checking. The MIT Press. guages (3) also called metamodels in MDE. Denckla, B., Mosterman, P., 2005. Formalizing In the context of systems where various points causal block diagrams for modeling a class of hy- of view have to be considered, functional metamod- brid dynamic systems. In: IEEE Conference on els are proposed to allow the description and the Decision and Control. composition of continuous behaviors (with numer- Deursen, A., Klint, P., Visser, J., 2000. Domain- ical and analytical models), of discrete behaviors specific languages: an annoted bibliography. In: (with state-transition models and a model of tem- SIGPLAN Notices. Vol. 35. pp. 26–36. poral logic used for specifications) and of concurrent Doets, K., van Eijck, J., 2004. The Haskell Road to behaviors (with models of actions and processes). Logic, Maths and Programming. College Publica- An other advantage of the concept is to be supported tions. by functional programming languages. In particu- Dubey, A., 2005. Metamodel based language and lar, the elements proposed have been implemented computation platform for algorithmic analysis of into Haskell. To show the benefits of the resulting hybrid systems. Ph.D. thesis, Faculty of the Grad- framework, the example of a control software sys- uate School of Vanderbilt University. tem is developed in part 5. Thus, as summarized on Favre, J.-M., 2004. Towards a basic theory to model Figure 1, functional metamodeling is used at three driven engineering. In: Workshop on Software levels with the systems, the languages and tools used Model Engineering, WISME 2004, joint event to model systems, and the means to specify these with UML2004. languages and tools. Guttag, J. V., 2002. Abstract data types and the de- Functional metamodeling offers an alternative to velopment of data structures. Software pioneers: the standards proposed by the MDE community contributions to software engineering, 453–479. that is better adapted to mathematical descriptions. Harisson, W., 2006. The essence of multitasking. In: In particular, functional metamodeling makes equa- Springer (Ed.), Lecture Notes on Computer Sci- tional reasoning possible and the first perspective ence. Vol. 4019. pp. 158–172. considered now will consist in studying how this ca- Henzinger, T. A., Sifakis, J., 2007. The discipline of pability can be used to prove model equivalences or embedded systems design. Computer 40 (10), 32– how properties of a model can be preserved by a 40. transformation, for instance. As a second perspec- Hudak, P., Courtney, A., Nilsson, H., Peterson, J., tive, studying how functional metamodeling can be 2003. Arrows, robots and functional reactive pro- applied to more software-oriented elements is con- gramming. In: Springer (Ed.), Lecture Notes on sidered. In particular, MDE adds concrete syntaxes Computer Science. Vol. 2638. pp. 158–172. to models, metamodels and models of transforma- Hudak, P., Hughes, J., S., P.-J., P.A., W., 2007. His- tions. The use of functional metamodels to spec- tory of haskell: Being lazy with class. In: 3rd ACM ify textual and/or visual views as a front end to Sigplan History of Programming Language. pp. the (meta)models presented here will give a better 1–55. understanding of the advantages/limitations of the Jantsch, A., Sander, I., 2005. Model of computation concepts. and languages for embedded systems design. In: Computer and Digital Techniques. Vol. 152. pp. 114–129. Lee, E., Varaiya, P., 2003. Structure and Interpre- tation of Signals and Systems. Addison Wesley. ”Models, metamodels and behavioral objects for Maler, O., 1998. A unified approach for studying complex dynamical systems”, at the Universit´ede discrete and continuous dynamical systems. In: Haute Alsace in 2002. His research interests include 37th IEEE Conference on Decision and Control. software engineering, model driven engineering, and Vol. 2. pp. 2083–2088. formal methods applied to control. Mathaikutty, D., 2005. Functional programming and metamodeling frameworks for system design. Bernard Thirion is a professor of software en- Ph.D. thesis, Faculty of Virginia Polytechnic In- gineering at the Universit´ede Haute Alsace (Mul- stitute and State University. house, France). He passed his Ph.D. (1980) in elec- Mc Ilroy, M., 1998. Functional pearls: Power series, tronics and instrumentation at the Universit´ede power serious. Journal of Functional Program- Haute Alsace, France. In 1993 he received a French ming 1 (1), 1–13. Habilitation for supervising research activities in Mellor, S., Clark, A., Futagami, T., 2003. Guest edi- software engineering at the Universit´ede Haute Al- tors introduction: Model-driven development. In: sace, France. His current research interests include IEEE Software. Vol. 20. pp. 14–18. software engineering and software architectures, Thielemann, H., 2004. Audio processing using UML and object-oriented modeling and metamod- haskell. In: 7th International Conference on Dig- eling, design patterns, design of concurrent and ital Audio Effects. real-time systems. Thirion, B., Thiry, L., 2002. Concurrent program- ming for the control of hexapod walking. ACM Ada Letters 22 (1), 17–28. Thiry, L., Thirion, B., 2008. Functional (meta)models for the development of control soft- ware. In: International Federation of Automatic Control, IFAC’08, Seoul. Uustalu, T., Vene, V., 2006. The essence of dataflow programming. In: Springer (Ed.), Lecture Notes on Computer Science. Vol. 4164. pp. 135–167. Vangheluwe, H., de Lara, J., 2003. Foundations of multi-paradigm modeling and simulation: com- puter automated multi-paradigm modelling. In: 35th conference on Winter simulation: driving in- novation. pp. 593–603. Varro, D., 2002. Towards symbolic analysis of visual modelling languages. In: International Workshop on Graph Transformation and Visual Modelling Techniques. pp. 57–70. Varro, D., Pataricza, A., 2003. Vpm: Mathematics of metamodeling is metamodeling mathematic. Journal of Software and Systems Modelling, 1–24. Wadler, P., 1996. The essence of functional program- ming. In: 19th Symposium on Principles of Pro- gramming Languages. Walter, R., 1992. Categories and Computer Science. Cambridge University Press. Winskel, G., Nielsen, M., 1995. Models for concur- rency. In: Press, O. U. (Ed.), Handbook of Logic in Computer Science. pp. 1–148.
Laurent Thiry is an assistant professor at the Universit´ede Haute Alsace (Mulhouse, France). He passed his PhD in software engineering, entitled